[condor-agent]

What broke

walletConfig.solana.sponsorFees routes a send through sendViaKora, which asked the paymaster to build the transfer with Kora's transferTransaction method. The Openfort Solana RPC endpoint stopped routing that method in d1bd249 (api, 2026-06-22), two days after the sponsored path shipped in #285. Every sponsored Solana send since then fails before broadcast:

RPC Error: Unknown method: transferTransaction.
Supported methods: getConfig, getPayerSigner, getSupportedTokens, getBlockhash,
estimateTransactionFee, signTransaction, signAndSendTransaction,
signAndSendTransactionWithoutConfirmation, estimateBundleFee, signAndSendBundle

This affects every project, on any sponsorship strategy. Unsponsored sends were never affected — they don't touch Kora.

What this does

Builds the transfer client-side. Native SOL through getTransferSolInstruction; SPL through an idempotent ATA creation (Kora pays the rent, as the fee payer) plus transferChecked. Kora remains the fee payer, the user's signature is injected the same way as before, and submission goes through signAndSendTransaction — all methods the endpoint routes.

Adds sponsorFees: { feeToken }. A gas sponsorship configured to charge the end user in an SPL token needs the user's transaction to carry the fee payment itself; sponsorFees: boolean had no way to name the mint. The payment is quoted with getPaymentInstruction and appended to the transfer. sponsorFees: true is unchanged and still means the project pays.

Replaces the paymaster-response guard. assertKoraInstructionsAreExpected existed because transferTransaction returned instructions the user would then sign blind. Those instructions are now built here, so the guard has nothing left to check. assertKoraPaymentIsExpected takes its place over the one value that is still the server's to decide — the fee payment — and refuses a payment instruction naming an account outside the fee transfer, a mint other than the one requested, or an unusable amount.

sendSplTokenGasless now takes decimals, which transferChecked requires. Both are internal to the package; no public export changed except the new SolanaFeeSponsorship type.

Dropping the marshalling through Kora's JS-number amount also removes the MAX_SAFE_INTEGER ceiling that sponsored SPL transfers used to hit.

Verification

pnpm check, check:types, test:types (896 tests), the unit suite (877 tests), build, size and build:docs all pass.

New tests in transfer.test.ts pin the behaviour that regressed: the sponsored path must not call transferTransaction, must submit through signAndSendTransaction, must append the quoted fee payment when a feeToken is configured, and must refuse a payment routed elsewhere. Per AGENTS.md the guard test was confirmed to fail with the guard removed.

Not covered: this has not been exercised against a live devnet paymaster from a browser. The RPC methods it now uses are the ones a customer's hand-rolled equivalent is already completing sends with in production, but a devnet smoke test through <OpenfortButton /> before release would be worth it.

Context

Reported by a customer on Solana devnet with a user-pays USDC sponsorship, whose own implementation against getPayerSigner / estimateTransactionFee / signAndSendTransaction works — which is the path this change adopts.

Prompted by: Joan Alavedra

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
playground	Ready	Preview	Sep 15, 2026 4:15pm UTC

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/@openfort/react@341

commit: c62ffed