Kora: fee abstraction so users never need SOL for gas

Every Solana transaction needs a fee payer with SOL. That is fine for power users and terrible for a USDC-only neobank or a game that only moves BONK. Kora is the Solana Foundation's answer: signing infrastructure that sponsors network fees while the user pays (or is subsidized) in whatever token your product already uses. It ships on Solana Launch as a first-class product with docs under solana.com/docs/tools/kora.

Click to zoom

What problem it solves

Apps where the native asset is not SOL hit the same wall: force a SOL top-up, or run a custom paymaster. Kora is the production-shaped paymaster pattern as open infrastructure — not a single hosted SaaS you must use, but a node you (or a partner) run with policy you control.

• Better UX — users never need SOL for gas
• Revenue control — collect fees in USDC, app token, or anything allowlisted
• Security posture — validation rules, program allowlists, rate limits, spend protection
• Ops — Redis caching, Prometheus metrics, HMAC / API key auth, flexible deploy (Docker, Railway, cloud)

How a Kora transaction works

1. User initiates action in your app
2. App builds tx including SPL payment ix to Kora operator
3. User signs (token authority / other required signers)
4. App POSTs signed tx to Kora JSON-RPC
5. Kora validates: programs, tokens, accounts, fee adequacy (oracle prices)
6. Kora co-signs as fee payer, returns fully signed tx
7. App submits to Solana
8. Network: SPL → operator, SOL fees from Kora, user intent executes

Kora is middleware between your app and the cluster. It introspects the transaction, checks it against node config, verifies fee payment covers market cost, then becomes the fee payer. Full Token-2022 support with extension filtering is a stated feature — important if your fee token is not vanilla SPL.

Stack surface

• Rust — kora-lib + kora-cli (cargo install kora-cli)
• TypeScript — @solana/kora client; Kit integration via createKitKoraClient() for planning, fee estimation, payment injection, submit
• Signers — Solana private key, Turnkey, Privy, Openfort (and related vault patterns)
• Auth — API key, HMAC, or open (operator choice)

import { KoraClient } from '@solana/kora';

const kora = new KoraClient({ rpcUrl: 'http://localhost:8080' });
const signed = await kora.signTransaction({ transaction });
// submit signed.transaction to your preferred RPC

Who runs a node

Three paths in the docs: quick local try, node operator deploy for production sponsorship, or app integrator using someone else's Kora endpoint. Operators own the risk: SOL inventory for fees, oracle dependency for pricing, policy misconfig that over-accepts bad txs. Treat operator runbooks as first-class product work, not an afterthought.

cargo install kora-cli
kora rpc --help

# from source
git clone https://github.com/solana-foundation/kora
cd kora && just install && just run

Security and honesty

Kora has been audited by Runtime Verification (report in-repo). The project tracks audited-through commits in audits/AUDIT_STATUS.md — main can mix audited and unaudited work; production should pin audited tags. The README also notes dependency on solana-keychain, which has its own audit story — read both before mainnet fee volume.

Where it sits on Launch

Kora is the fee layer of the Solana Launch stack: CommerceKit and Solana Pay handle checkout UX; Kora removes SOL from the gas path; Keychain unifies backend signing. For agentic / machine payments, pair with your agent payments design — fee abstraction is orthogonal to who initiates the transfer.

Resources

• launch.solana.com · Kora docs
• github.com/solana-foundation/kora · crates.io kora-cli · npm @solana/kora
• Stack Exchange tag kora · related: solana-keychain, CommerceKit