SIP: Standard for Gasless Transactions (Fee Delegation)
Simple Summary
Enable gasless transactions on Solana via a standardized meta-transaction protocol. This proposal introduces a common method for users to pay transaction fees with SPL tokens (or have them sponsored) instead of SOL, by leveraging Solana’s existing fee payer field and atomic transaction capabilities. It defines a unified architecture – including transaction format, a relayer network API, and wallet/dApp integration guidelines – to eliminate the “must have SOL” onboarding hurdle while preserving Solana’s security and low-fee advantages.
Abstract
We propose a Standards Track (SRC) Solana Improvement Proposal to standardize fee delegation (a.k.a. gasless transactions) across the ecosystem. The core idea is that a user can sign a transaction that performs their intended action plus an additional fee payment in a token they already hold (e.g. USDC), and a third-party relayer will co-sign as the fee payer (paying the SOL fee) in exchange for that token fee, all in one atomic transaction. We outline a standard transaction format (with a fee-paying SPL token instruction), a common Relayer API for discovering and using relayer services, and modifications for wallets and dApps to seamlessly support this flow. This standard builds on existing practices (Octane, Kora, Gas Station API, etc.) but seeks to unify them, providing a consistent “meta-transaction” mechanism so that new users can use Solana dApps without first acquiring SOL. Validators still receive fees in SOL (paid by relayers), but users and developers gain flexibility in how fees are provided, improving UX without requiring any consensus changes.
Motivation
Despite Solana’s very low base fees, requiring SOL in a wallet to cover fees is a significant UX hurdle for newcomers. New users face a “chicken or egg” problem: they receive tokens (e.g. USDC airdrop or NFT) but cannot do anything without first obtaining SOL for fees. As one user lamented: “I transferred all I had into USDC and now trying to swap… it is asking for a SOL fee 
… Why do I need SOL in my wallet to swap USDC to SOL?!”
Solana’s protocol supports fee delegation: every transaction has a feePayer field. Some projects have implemented “gasless” services: Octane, Kora, Phantom’s mobile app gasless swaps, Circle’s Gas Station API. However, these solutions remain fragmented and non-standard. Each dApp wanting a SOL-free experience often integrates a proprietary relayer or builds their own. Octane was pioneering but not maintained and required custom integration.
This SIP aims to solve that by codifying a unified meta-transaction standard, so any Solana dApp or wallet can support gasless transactions out-of-the-box, using a common set of protocols and interfaces.
Use Cases
- Basic Token Transfers Without SOL: Alice wants to send Bob USDC but has zero SOL. With a relayer, Alice signs a transaction to pay Bob in USDC and include a tiny USDC fee to a relayer.
- Swaps and DeFi Operations: Users hitting “no SOL, no swap” issues could swap from USDC→SOL including a USDC fee to a relayer, enabling the trade even with empty SOL balance.
- NFT Mints and Airdrops: Users receiving NFTs with no SOL cannot list or transfer them. Fee sponsorship allows NFT platforms to enable listings by accepting SPL token fees.
- Smart Contract Wallets & PDAs: Programmatic wallets or PDAs that cannot hold SOL or sign transactions require external fee payers. Standard relayer services can facilitate these transactions.
- Embedded and Mobile Wallets: In-game or embedded app wallets want completely abstracted gas. A standardized relayer API allows easy integration.
- Onboarding New Users: User installs a wallet or opens a web app and is granted starter tokens. Using gasless transactions, the app gives them a feeless first action, removing the confusing step of acquiring SOL.
Specification
The proposed standard has three main components: (1) Transaction Format, (2) Relayer Service & API, and (3) Wallet/dApp Integration.
1. Transaction Format (Meta-Transaction Structure)
A gasless meta-transaction on Solana includes:
Fee-Payer Field: The transaction’s feePayer is set to the relayer’s public key (not the user’s). This signals the relayer will cover the fee.
Fee Payment Instruction: The transaction includes an instruction transferring SPL token from user to relayer as payment. Typically the last instruction so it only executes if all prior instructions succeed. For example, swapping 100 USDC for SOL might include an extra instruction transferring 0.05 USDC to the relayer.
Partial Signing: The user signs first, but because the feePayer is someone else, the transaction isn’t valid for submission yet. The partially signed transaction is serialized (e.g. to base64) and sent to the relayer service off-chain.
Relayer Co-signing: The relayer receives the transaction, validates it, and if it meets criteria, signs with its fee payer key and submits the fully signed transaction to the network.
Below is a conceptual diagram of this transaction flow, as pioneered by Octane and similar services:
User constructs transaction with desired action and token fee payment to relayer → User signs → Sends to relayer → Relayer verifies and signs as fee payer → Broadcasts → Token fee atomically transferred to relayer upon success.
Fee Calculation approaches:
- Fixed Fee: Flat rate in token (e.g. 0.01 USDC per transaction)
- Dynamic Conversion: Use oracle price feed to convert SOL fee into equivalent token amount
- Percentage of Transaction: Charge percentage of output (e.g. Phantom’s 0.65% premium)
The standard requires fee be explicitly included as on-chain instruction for atomicity. If fee transfer fails, transaction fails and relayer doesn’t pay SOL.
FeePool Program (Optional): A canonical on-chain Gas Fee Pool program could standardize the fee payment instruction. Instead of direct transfers, transaction calls an instruction on this program, e.g. PayWithToken {fee_token_mint, fee_amount, relayer_address}. The program would transfer from user to relayer with on-chain checks (price oracle verification, minimum fee requirements). This is optional; relayers may accept direct token transfers.
2. Relayer Service and API
Relayer Network: Independent relayer services compete to sponsor transactions in exchange for fees. Each relayer differentiates by supported tokens, pricing, features, security policies, and performance.
Common Relayer RPC API (HTTP/JSON):
getSupportedTokens– Returns list of SPL token mints the relayer accepts for fee paymentfeeEstimate– Takes proposed transaction and chosen fee token, returns required token amounttransactionPrepare– Takes unsigned/partially signed transaction, returns it with fee payment instruction addedtransactionSign– Takes fully prepared transaction and signs with relayer’s fee payer key without broadcastingtransactionSignAndSend– Main endpoint: takes partially signed transaction, validates, signs as fee payer, and broadcasts to networktransactionSend– Broadcasts fully signed transaction to network
Relayer Validation & Policies:
- Correct Fee Payment: Ensure transaction contains fee payment instruction to relayer’s account with sufficient amount
- No Malicious Instructions: Inspect all instructions to ensure relayer’s fee payer account isn’t misused. Reject transactions where fee payer is included as normal account in an instruction
- Simulation/Validity: Simulate transaction before signing to ensure it will succeed
- Price Check: Validate via oracle that token amount meets required SOL value
- Expiration: Enforce transactions only accepted within certain time or block height window
- Rate Limiting & Spam Control: Impose limits per user to prevent spamming
- Logging and Monitoring: Maintain logs and metrics for reliability
Discovery of Relayers: List of known conformant relayers published (on website, GitHub, or on-chain registry). Future marketplace where relayers compete on fees.
3. Wallet and dApp Integration
Wallet Support: Wallets should recognize gasless transactions with alternate fee payer and handle gracefully. Display “Fee paid by third party” in UI. Implement features like “auto-gasless for low SOL balances” by automatically invoking relayers.
dApp Developer Usage:
- Rely on user’s wallet to handle fee delegation, or
- Directly integrate with relayer API
Common integration pattern:
- Backend creates transaction, sets relayer as fee payer, adds fee payment instruction, partial signs
- Sends to user’s wallet for signing
- Wallet signs with user’s key
- Fully signed transaction broadcast to network
Standards for User Prompting: Wallets should display transparently: “Network Fee: 0 SOL (Paid by relayer, costing you 0.05 USDC)”. Consistency reduces confusion.
Security & Permissions: If wallet automatically uses relayers, user should trust their wallet. Possible setting: “Allow third-party relayers to pay fees when I have insufficient SOL”.
Fallbacks: Handle relayer failures gracefully. If relayer returns error, inform user to try different token or acquire small SOL amount.
Rationale
Do Nothing / Status Quo: Low fees aren’t enough. Real-world user feedback shows small hurdles have outsized negative impact on growth. Multiple one-off solutions (Octane, Gas Station) evidence the problem is significant.
Protocol Change: Not necessary. Solana’s flexible runtime and atomic transactions with alternate fee payer already provide needed flexibility. Standardizing at ecosystem level (off-chain and program layer) avoids complexity and risks of core changes. Validators continue receiving SOL fees.
Single Relay Network vs Multiple Relayers: Single network would be centralized chokepoint. Permissionless marketplace of relayers fosters competition and avoids centralization. Standard API ensures switching is easy.
Choosing Best Existing Approach:
- Octane demonstrated viability but wasn’t production-hardened
- Kora is robust, uses Rust, provides JSON-RPC API, TypeScript SDK, strong validation (price oracles, allowlists), enterprise-grade (HSM support, monitoring, configurable policies)
- Gas Station provides fee-sponsoring but not open standard
- Phantom’s gasless swap is closed implementation
Our approach takes best elements: Octane’s simplicity, Kora’s rigor and polish, wallet integration usability focus. Off-chain relayer + on-chain token payment model requires no protocol change, proven in wild, maximizes flexibility.
Oracle vs Fixed Fee: Allow but not require on-chain oracles (optional FeePool program). Mandating on-chain price check adds overhead and failure point. Many relayers handle pricing off-chain with buffer. Competition keeps fees reasonable.
Backward Compatibility
No changes to core protocol or runtime required. All features use existing transaction format and programs (SPL Token) or new programs at application level.
Existing wallets/dApps that don’t implement this standard continue functioning with no impact. Transactions following this standard remain valid Solana transactions.
FeePool program (if introduced) is new on-chain program deployment, doesn’t affect existing programs or accounts.
Partial sign transactions are already standard practice (QR codes, multisig workflows). Non-upgraded wallets might not auto-assist, but developers can handle via SDKs.
Client SDKs (Web3.js, Anchor) can already construct transactions with custom fee payers. Documentation will be provided.
Test Cases
1. Basic Token Transfer (User with 0 SOL):
- Without SIP: Alice’s transfer fails due to no SOL for fee
- With SIP: Wallet constructs transaction with feePayer = relayer, instructions: [Transfer 5 USDC Alice→Bob, Transfer 0.02 USDC Alice→Relayer]. Alice signs, wallet sends to relayer API, relayer signs and broadcasts. Bob gets 5 USDC, relayer gets 0.02 USDC.
2. Token Swap via dApp:
- dApp calls relayer feeEstimate, quotes 0.03 USDC fee
- Constructs transaction: feePayer = relayer, instructions: [USDC→SOL swap, Transfer 0.03 USDC Carol→Relayer]
- Carol signs, dApp sends to relayer, relayer verifies, signs, broadcasts
- Carol receives SOL, relayer gets 0.03 USDC
3. Smart Contract Wallet: App sets up relayer as fee payer for PDA transaction. PDA transfers token to relayer via FeePool instruction, relayer covers SOL fee.
4. Insufficient Token Fee: Eve’s token fee is below minimum value. Relayer simulation catches insufficient fee, responds with error or new quote. Eve’s wallet informs of updated requirement.
Implementation
Reference implementation: Kora (Solana Foundation open-source) aligns with many aspects of proposal. Provides RPC API, core engine with validation, SDKs for integration.
Steps needed:
- Finalize SIP and Community Consensus
- Publish Standard Specification v1.0 (formal document with API schema)
- Implement FeePool On-Chain Program (optional)
- Encourage Relayer Implementations (multiple implementations of standard API)
- Wallet Integration (work with Phantom, Solflare, Glow, etc.)
- dApp Developer Tools (examples, wrappers, documentation)
- Deployment and Testing on Testnet/Devnet
- Mainnet Rollout (Foundation-run relayer to bootstrap, wallets push updates)
- Monitoring and Iteration (collect metrics, feedback channels)
- Ecosystem Growth (specialized relayers, MEV integration, etc.)
Kora expected to be released around late 2025, boasting secure validation, rate limiting, monitoring built-in.
Security Considerations
Relayer SOL Theft: Standard requires relayers validate transaction and reject any attempting to misuse fee payer’s signature. Strictly disallow fee payer key being signer for any instruction other than paying fee.
Fee Token Valuation Risks: Relayers restrict supported tokens to those with sufficient liquidity and reliable value. Price conservatively, use real-time oracles, offload accumulated fee tokens periodically.
DoS and Spam: Authentication (API keys), rate limiting, transaction fees for frequent users, robust infrastructure, fallback to multiple relayers.
Double Signing/Replay: User submitting same transaction to multiple relayers is mitigated by each requiring their own fee account. Relayers use unique identifiers, quickly broadcast. Blockhash expiration limits replay window.
User Scams/Phishing: Wallet UI should highlight “You will pay X tokens as fee to Y (relayer)”. Users should be wary of unusually high token fees.
Relayer Trust: Users trust relayer to broadcast transaction honestly and not front-run. Use reputable relayers, open-sourced and audited code. Dishonest relayers lose business quickly.
FeePool Program Security: If used, must verify token transfer is authorized, handle edge cases, use trusted oracle feed with fallback, ensure atomicity. Open source and audited.
Compliance: Operators should be mindful of local laws regarding running relayer services.
Security model: User trusts relayer only to perform service honestly, not with assets. Relayer trusts that following standard checks prevents money loss. Blockchain security unchanged.
Conclusion
This proposal addresses a key UX pain point by establishing unified framework for gasless transactions. Allows users to pay fees in tokens they hold (or have fees sponsored entirely), removing significant barrier to entry while leveraging Solana’s strengths.
Benefits:
- Improved User Acquisition and Retention: New users start using dApps immediately
- Developer Ease and Interoperability: Well-defined standard instead of hacking together relayers
- Ecosystem Collaboration: Standardized relayer network encourages businesses to provide services
- Flexibility for Future Innovation: Base for sophisticated fee models (decentralized marketplaces, MEV integration)
Next steps: formalize API and integration details, implement supporting program, coordinate adoption. Given enthusiasm around Kora and sRFC-34 discussions, timing is ideal.
Let’s make “Please ensure you have at least 0.005 SOL in your wallet to cover fees” a thing of the past, and welcome truly user-friendly blockchain applications on Solana 