Solana's Kora Fee Relayer: Gasless UX in Any SPL Token — and Who Actually Pays the Bill

Solana's fees are famously tiny — the base fee is 5,000 lamports per signature, a fraction of a cent. And yet that fraction of a cent has been one of the chain's most effective user repellents, because of a circular trap every new wallet hits: you need SOL to pay the fee on your first transaction, but you can't move anything into or out of your wallet without paying that fee. A user holding $500 of USDC in a fresh Solana wallet is, functionally, holding nothing — until someone airdrops them a few cents of SOL or they complete a KYC'd exchange purchase just to cover gas. Kora, a fee relayer and signing node maintained by the Solana Foundation, is the first production-grade, audited, self-hostable piece of infrastructure aimed squarely at deleting that step.

The mechanism fits in five steps, and it's worth seeing up front because everything else in this post hangs off it:

1. The app builds a transaction that includes an extra instruction: a token payment (USDC, BONK, an in-game token — any allowlisted SPL token) to the Kora operator's address.
2. The user signs it — with a wallet that holds zero SOL.
3. Kora validates the transaction against the operator's configured rules: allowlisted tokens and programs, transaction limits, and a check that the token payment actually covers the fee at current prices.
4. Kora co-signs as the fee payer — Solana's transaction format natively designates the first signer as the account that pays the network fee, and that account doesn't have to be the user.
5. The transaction is submitted. The network fee is paid in SOL from the operator's wallet; the user paid in the token they already had.

No new smart contracts, no wrapped accounts, no protocol change. Let's be precise about the tax it removes, who ends up paying it instead, and why Ethereum needed an entire account-abstraction standard to build what Solana got from a transaction-format decision.

The "Must Hold SOL" Tax, Quantified​

Solana's fee model is simple and cheap. Per the official fee documentation:

• Base fee: 5,000 lamports per signature (0.000005 SOL). Half is burned; half goes to the validator.
• Priority fee (optional): ceil(compute_unit_price × compute_unit_limit ÷ 1,000,000) lamports, 100% to the validator. Default per-instruction compute limit is 200,000 units; a transaction caps at 1.4 million.

At any plausible SOL price, a typical transaction costs well under a cent. The tax isn't the amount — it's the precondition. A wallet with 0 SOL cannot execute anything: not a token transfer, not an account creation, not a swap. The fee is small, but it's a hard gate, and it lands on exactly the people you least want to lose:

• First-time users onboarded via a stablecoin transfer or an NFT claim, who have never bought SOL and shouldn't need to.
• Payment-app users who think in dollars and hold USDC. "First, acquire a volatile asset on an exchange" is a fatal onboarding sentence.
• Game players holding a title's native token, who have no idea what a lamport is.
• AI agents provisioned with a budget in one task-specific token — more on these later.

Where the tax actually goes (it doesn't vanish)​

Be clear-eyed about one thing: Kora does not make Solana fees disappear. Every transaction still burns and pays its lamports. What changes is who fronts them. The Kora operator — the app team, or an infrastructure provider running Kora as a service — maintains a SOL reserve in the fee-payer wallet and spends from it on every sponsored transaction. The operator then recoups that cost (or deliberately eats it as a customer-acquisition expense) through the token payment instruction, priced via an oracle at a rate the operator configures.

So the honest description is: Kora relocates the SOL requirement from every end user to one operator, and converts it from a UX precondition into a line item. That's not a diminishment — it's the entire point. One party that's good at holding SOL, monitoring balances, and managing spend replaces a million parties who are bad at it and would have churned instead. The onboarding tax dies for users precisely because someone whose job it is to pay it does so, visibly, with metrics.

How It Works: Fee-Payer Separation at the Protocol Level​

The reason Kora can be this simple is a property Solana has had since day one: the fee payer is just the first signer of a transaction, and it doesn't have to be the wallet whose tokens move. Fee-payer/signer separation is native to the transaction format. Sponsoring someone's fee requires no contract, no proxy account — only a second signature on the same transaction.

Kora packages that primitive into an operable service (github.com/solana-foundation/kora):

• A Rust node exposing a JSON-RPC 2.0 API — the same protocol shape as a Solana RPC endpoint, so it slots into existing client stacks.
• A TypeScript SDK (@solana/kora) where a client calls signTransaction() to get the paymaster's co-signature; createKitKoraClient() integrates with the Kit plugin architecture and handles transaction planning, fee estimation, and injecting the token-payment instruction automatically.
• Pricing oracles — Jupiter for live token-to-SOL conversion rates, or a mock oracle for testing — so the operator can verify that the USDC (or BONK, or anything allowlisted, including Token-2022 assets) attached to a transaction actually covers the SOL it will cost.
• Two sponsorship modes: fully gasless (the app absorbs fees — free mints, onboarding flows) or token-denominated (the user pays, just not in SOL).

The flow is the five steps from the top of this post. What the architecture buys you is that steps 3 and 4 — validation and co-signing — happen inside infrastructure you control and can audit, not inside a third-party black box with your fee budget attached.

Running a Node: kora.toml, Remote Signers, and Guardrails​

An unguarded fee payer is a faucet — anyone who can reach it can drain its SOL. Most of Kora's surface area is guardrails, configured in a kora.toml file, and this is where the operator documentation earns the "production-ready" label:

• Token allowlists — which SPL and Token-2022 tokens you accept as fee payment, with the ability to block specific Token-2022 extensions (an extension like transfer hooks on an unvetted token is attack surface).
• Program whitelists and account blocklists — refuse to sponsor transactions touching programs you haven't approved.
• Fee-payer policies — constrain what the fee-payer key itself can be made to do inside a sponsored transaction: block transfers, burns, approvals, and other operations so a malicious transaction can't smuggle in an instruction that moves the operator's own funds.
• Per-wallet usage limits and rate limiting — cap how much subsidy any single wallet can extract; this is also how you run deliberate free-transaction promotions without an open faucet.
• Redis caching for RPC-call reduction, and a Prometheus /metrics endpoint covering SOL balance, relay latency, and per-token payment patterns — low-fund alerts before your paymaster runs dry, spend anomalies before they become incidents.

Signing without the key in application memory​

The fee-payer key signs everything, so it's the crown jewel. Kora supports pluggable signer backends so that key never has to sit in your app server's memory: a local private key (fine for development), or remote signing via Turnkey, Privy, or HashiCorp Vault (the README also lists Openfort). Signing moves into dedicated key-management infrastructure with its own access controls and audit trails — the posture institutional custodians use, available to any team that can run a config file. (Early coverage of Kora floated AWS KMS and Google Cloud KMS backends; as of this writing the official docs list the backends above, so plan against those.)

The audit​

Kora was audited by Runtime Verification, with the report (dated November 19, 2025) published in the repository, and — unusually and commendably — the repo tracks the audited-through commit and the current unaudited delta in AUDIT_STATUS.md. One flagged caveat: the solana-keychain dependency has not been independently audited. For teams deciding whether to put a SOL-holding hot wallet behind an open endpoint, a published audit plus an honest statement of what it doesn't cover is the difference between a research prototype and something you can defend in a security review.

Kora vs. Ethereum's ERC-4337 Paymasters​

Ethereum has been solving the same UX problem — users without the native token can't transact — since 2021, and the comparison is instructive because the two chains solved it at different layers.

The pattern: Ethereum's account model has no native fee-payer separation, so ERC-4337 rebuilds transaction handling in smart contracts — EntryPoint, bundlers, staked paymasters, a parallel mempool — to get it. Solana had the separation at the protocol level from the start, so "gasless" needed no on-chain machinery at all, just a trustworthy co-signer. That's why Kora can be architecturally boring: a config file, a signer backend, and a JSON-RPC endpoint.

The honest trade-off runs the other way too. A 4337 paymaster's guarantees are on-chain and trustless; a Kora operator is a trusted party who could censor or go down. Solana's answer to that is not cryptography but operational: the relayer is open-source MIT-licensed software, so the trust question becomes "run your own or pick a provider" — the same decision you already make about RPC nodes.

Agents, Token-Only Wallets, and the Coming Managed-Kora Market​

The most interesting Kora users may not be human. An AI agent provisioned to do a job — pay invoices in USDC, trade an in-game asset, settle API metering — is the purest case of the onboarding tax: it holds exactly the token its task requires, and bolting on "also acquire and custody a volatile gas asset, and monitor its balance" multiplies the operational surface of every agent you deploy. With a Kora endpoint, an agent funded only with USDC can transact on Solana indefinitely; fee logistics are centralized in one relayer with rate limits, spend caps, and Prometheus metrics — infrastructure state a fleet operator can actually monitor, instead of a thousand tiny SOL balances that each fail silently. That's a concrete argument in Solana's favor for agent-initiated payment flows, where Ethereum-side equivalents route through 4337's heavier stack.

It also reshuffles the RPC-provider market. Helius, Triton, QuickNode and their peers sell Solana access; Kora gives every one of them an obvious adjacent product — managed paymaster — while the MIT license simultaneously guarantees teams can self-host instead. Expect both to happen: managed Kora for teams that want fee sponsorship as a checkbox, self-hosted Kora for teams that treat the fee wallet as too sensitive to outsource. If "stablecoin-denominated fees by default" becomes the norm for consumer apps, the winners of that market decide a meaningful slice of Solana UX.

And self-hosting it is deliberately unexotic: Kora ships as a Rust binary with Docker packaging, a config file, Redis as an optional sidecar, and a metrics endpoint — the docs' deploy targets are Docker, Railway, or your own cloud. It's a git repo that needs to become a monitored HTTPS service, which is exactly the shape of problem a self-hosted PaaS exists for.

If you'd rather run infrastructure like Kora on machines you own — push the repo, get a running HTTPS service with TLS and metrics, no per-service platform bill — that's what Bex.co is for: the open-source, AI-native Render alternative. Star the repo on GitHub or deploy your first service today.

Sources​

• Kora repository — Solana Foundation
• Kora documentation: getting started
• Kora documentation: node operators
• Solana fee documentation
• Alchemy: What is a paymaster? (ERC-4337)