Allow SPL Token Fee Payment Instructions for Solana Smart Wallets

[maxsch-xmint]

Allow SPL Token Fee Payment Instructions for Solana Smart Wallets

Note: The use cases described in this issue assume the external wallet involved is a treasury wallet controlled by the wallet provider. The proposed validation constraints are designed with this in mind.

Context

[PR #1380] adds support for Solana Smart Wallets, starting with a Swig-based implementation, and lays the foundation for easily extending support to new wallet providers.

Problem

Solana Smart Wallets can support a "pay fees with SPL tokens" model, where the wallet provider charges its fee in SPL tokens (e.g. USDC) rather than SOL. This requires an additional instruction in the transaction: an SPL token transfer from the user's wallet to an external wallet.

This is a common pattern for achieving a gasless UX on Solana — the user never needs to hold SOL, and all costs are settled in the same token used for the payment itself.

Proposal

We'd like to request that the facilitator allows this additional SPL token transfer instruction, subject to strict constraints:

• The transfer is an SPL token transfer (e.g. USDC)
• The sender is the user's wallet
• The recipient is the treasury wallet (i.e. not the fee payer, and not any merchant address)

These constraints make the instruction narrowly and verifiably scoped to a wallet provider fee, with no value flowing to the merchant or the facilitator.

Related: Rent Sponsorship Instruction

In some cases, a second extra instruction may also be present: a SOL transfer from the treasury wallet to the user's wallet, used to pre-fund the rent exemption cost when a new on-chain account needs to be created. The constraints here would be:

• The transfer is SOL
• The sender is the treasury wallet (neither the fee payer nor the user's wallet)
• The recipient is the user's wallet address

This is the complementary direction of the same treasury relationship — the wallet provider briefly funds the user to cover account initialization, which is then offset by the SPL fee payment above.

Why This Is Safe

We understand that the current model intentionally treats account funding as an out-of-band process, partly in response to past griefing attacks where malicious merchants drained facilitators by forcing the creation of large numbers of new accounts.

This proposal is different in a few key ways:

• Both instructions involve an external wallet (in practice, a treasury controlled by the wallet provider), not the merchant or facilitator
• The constraints above make it trivially verifiable that no value flows unexpectedly away from the user or fee payer
• The logic is narrow and deterministic — it can be validated at the instruction level before signing

Question

Would it be acceptable to allow these instructions under the constraints described above? Happy to discuss the validation logic in more detail or adjust the approach to fit your security model.

[maxsch-xmint]

@notorious-d-e-v @phdargen @CarsonRoscoe would like to hear about your thoughts here.

[BranchManager69]

This is addressed by simulation-based outcome verification in #1527.

The core issue here is that the positional instruction allowlist needs to grow every time a new instruction pattern appears in smart wallet transactions. Wallet provider fees today, rent sponsorship tomorrow, something else next week.

With outcome-based verification, the facilitator doesn't inspect individual instructions. It simulates the transaction with innerInstructions: true, extracts all TransferChecked from the CPI trace and top-level instructions, and matches exactly one against the payment requirements (exact mint, destination ATA derived from payTo, exact amount). Everything else in the transaction — wallet provider fee transfers, rent pre-funding, precompile verifications — is irrelevant to the payment verification.

The constraints you described (sender is user wallet, recipient is treasury, not fee payer or merchant) are implicitly satisfied: the facilitator only cares that the payment transfer is correct. Additional transfers between the user and their wallet provider don't affect the verification outcome.

Fee payer isolation ensures the facilitator's funds are protected regardless of what other instructions exist. Compute budget caps bound fee exposure. Simulation proves the transaction would succeed on-chain.