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 signing / paymaster infrastructure: sponsor network fees in SOL while the user pays (or is subsidized) in whatever token the product already uses.

Home: sola.na/kora. Docs: launch.solana.com/docs/kora. Part of Solana Launch. This page refreshed against the repo as of v2.2.0-beta.8 (July 2026) and current main operator docs.

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 that paymaster as open infrastructure — a node you (or a partner) run with policy you control, not a single mandatory hosted SaaS.

• UX — users never need SOL for gas
• Revenue — collect fees in USDC, app token, or allowlisted SPL; or run free/subsidized pricing
• Policy — program/token allowlists, fee-payer instruction policies, rate limits, usage limits, optional reCAPTCHA
• Ops — Redis cache, Prometheus, HMAC/API key auth, Docker/Railway-style deploy, signer health + failover

How a Kora transaction works

1. User initiates action in your app
2. App builds tx including SPL payment ix to Kora operator (unless free pricing)
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 (optionally adds Lighthouse assertions)
7. App submits fully signed tx to Solana (or uses signAndSend*)
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 node config, verifies fee payment covers market cost (margin / fixed / free pricing), then becomes the fee payer. Full Token-2022 support with extension filtering matters when the fee token is not vanilla SPL.

Stack surface (current)

• Rust — kora-lib + kora-cli (cargo install kora-cli); latest line 2.2.0-beta.8 on crates / GHCR
• TypeScript — @solana/kora (stable npm line and 0.3.x betas); Kit integration via createKitKoraClient() and a dedicated /kit subpath so the main entry stays lean
• Signers — local key, Turnkey, Privy, Openfort / vault patterns via solana-keychain adapters; remote signer timeouts + pool health monitoring and automatic failover
• Auth — API key, HMAC (timestamp skew), optional reCAPTCHA v3 on sign methods, or open
• Docker — ghcr.io/solana-foundation/kora:v2.2.0-beta.8 (also :beta)

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

// Prefer createKitKoraClient() when on Solana Kit —
// plans, estimates fee, injects payment, submits.

What v2.2 adds for operators and integrators

The 2.2 beta line is less “new product category” and more production hardening around the fee payer — the account attackers try to drain when a paymaster is naive.

• Fee-payer protection — granular validation.fee_payer_policy for System, nonce, SPL Token, Token-2022, and ALT instructions (what the fee payer may transfer, create, assign, close, etc.). Hardening PRs cover ATA rent drain, net-zero payment tricks, loader CreateAccount pairing, deploy-authority drains, multisig co-signers, ALT close outflow, and nonce withdrawal when the fee payer is authority.
• Lighthouse integration — optional on-chain balance assertions (kora.lighthouse). Important constraint: only fits signTransaction / signBundle flows where the client can re-sign after Kora mutates the tx — not signAndSend*.
• Validation rules — must_call_programs / require_one_of_programs, block compute-only txs, cross-cluster mint checks, Token-2022 extension allow/deny (including transfer-hook policy), usage limits that enforce all-or-nothing and stay atomic under concurrency.
• V0 / bundles — batch-fetch and cache address lookup tables; bundle-aware fee estimation (e.g. cross-leg ATA creation); sequential simulation paths before signing when appropriate.
• Config honesty — deny_unknown_fields on kora.toml so typos fail closed; process exit 1 on invalid config; structured numeric RPC error codes.
• Payment surface growth — p-token batch/lamport instructions, CreateAccountAllowPrefund, loader-v3/v4 deploy policies, optional DeployAuthority plugin for devnet-deploy-style paymasters.
• Pricing / oracle — margin, fixed, or free; payment-side price cache + HTTP timeouts; strict fixed pricing when a quote floors to zero.

Recent repo work (late July 2026) also added fuzz / property tests around fee-payer drains and CI fuzz targets — treat that as signal that fee-payer safety is the active threat model.

Config sketch

Operators drive behavior from kora.toml. Illustrative shape (see the repo example for the full matrix):

[kora]
rate_limit = 100

[kora.auth]
# api_key = "..."
# hmac_secret = "..."
# recaptcha_secret = "..."

[kora.lighthouse]
enabled = false
# only with signTransaction / signBundle (+ client re-sign)

[kora.cache]
enabled = false
url = "redis://localhost:6379"

[validation]
max_allowed_lamports = 1_000_000
max_signatures = 10
price_source = "Mock"   # production: real oracle
allowed_programs = [
  "11111111111111111111111111111111",
  "TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA",
  # ...
]
allowed_tokens = ["EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v"]  # USDC

[validation.price]
type = "margin"  # free | margin | fixed
margin = 0.1

[validation.fee_payer_policy.system]
allow_transfer = true
allow_create_account = true
# ... nonce / spl_token / token_2022 / alt subsections

Who runs a node

Three paths: quick local try, node operator for production sponsorship, or app integrator against someone else’s Kora endpoint. Operators own SOL inventory, oracle dependency, and the blast radius of a loose allowlist. Prefer signTransaction + client submit when you want Lighthouse or maximum client control; use signAndSend* only when the trust model matches.

cargo install kora-cli
kora rpc --help

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

# container
docker pull ghcr.io/solana-foundation/kora:v2.2.0-beta.8

Security and honesty

Kora has been audited by Runtime Verification (report in-repo). The project tracks audited-through commits in audits/AUDIT_STATUS.md. Branch model (March 2026): main is integration and may mix audited and unaudited commits — production should pin audited tags/snapshots. README still notes solana-keychain as not covered by that audit story; read both before mainnet fee volume. See also solana-keychain backends.

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. Candide-style paymasters and Imperial/perps fee paths are different products; Kora is the Foundation open-relayer shape for general app txs.

Resources

• Kora docs (Launch) · operators · JSON-RPC · Kit client
• github.com/solana-foundation/kora · crates kora-cli / kora-lib · npm @solana/kora · GHCR ghcr.io/solana-foundation/kora
• Stack Exchange tag kora · related: keychain, CommerceKit, Candide paymaster

Bottom line

Kora remains the open Solana paymaster: SPL (or free) fees for users, SOL sponsorship for operators, JSON-RPC + Rust CLI + TypeScript/Kit SDK. The v2.2 line is about not getting the fee payer drained — fine-grained policies, Lighthouse asserts, stricter config, better simulation and ALT handling. Run it if you need gasless UX under your own allowlist; pin audited releases and treat operator policy as security code.