DEV Community: Mitch

Gasless Transactions on Solana

Mitch — Tue, 04 Nov 2025 10:03:14 +0000

Two years ago, I walked into my first ever crypto event as a complete outsider. When the presenter asked a question, I raised my hand. Boom $3 straight to my wallet for a correct answer. I was genuinely excited. Real digital money I could actually spend, right? Wrong. What followed was a painful lesson in crypto's biggest UX flaw: I needed to buy a completely different token just to move the money I'd earned. Standing there confused, holding dollars I couldn't spend without SOL I didn't have, I thought exactly what millions of first-time users think: this whole thing is a scam.

That frustration stuck with me. Not because I'm bitter about three dollars, but because I realized this broken experience is repeated thousands of times daily across the ecosystem. Kora is built to remove that friction. To see how it does it, we need to first understand why this point of friction even exists in the first place.

How Solana Transactions Normally Work

Every interaction on Solana runs through a transaction. A transaction is nothing more than a container of instructions, each telling an on-chain program what to do. Those programs define the rules, what operations are valid, how accounts are updated, and what conditions must be met. Think of an instruction as a function call to an on-chain program, telling it to perform a particular task and on the other hand a transaction is just a package of one or more instructions. Transactions on Solana are by default atomic in nature—either all instructions succeed or the whole transaction fails

Sounds clean. But here's the catch: every transaction needs SOL. Always.

Example: David Sends SOL to Samuel.

Account Structure: Both wallets (David and Samuel) are accounts owned by the System Program
- Each account maintains:
  - Lamports (SOL balance): 1 SOL = 1 billion lamports
  - Owner (System Program for wallets)
  - Data (usually empty for wallets)
  - Executable flag (false for wallets)
Transaction Construction and Signing
- David constructs a transaction with a SystemProgram.transfer instruction
- He signs the transaction and submits it to the network
Validator Processing
- The validator simulates and executes the transaction
- Upon execution, the System Program, since it owns both accounts deducts lamports from David and credits Samuel

The sender account (David) must sign (is_signer) the transaction to authorize the System Program to deduct from its lamports balance. Both sender and recipient accounts must be writable (is_writable) since their balances change during the transfer.

In practice this is how to send a transaction that transfers SOL from one account to another:

use anyhow::Result;
use solana_client::nonblocking::rpc_client::RpcClient;
use solana_sdk::{
    commitment_config::CommitmentConfig, native_token::LAMPORTS_PER_SOL,
    signature::Signer,
    signer::keypair::Keypair, system_instruction, transaction::Transaction,
};

#[tokio::main]
async fn main() -> Result<()> {
    // Create a connection to cluster
    let connection = RpcClient::new_with_commitment(
        "http://localhost:8899".to_string(),
        CommitmentConfig::confirmed(),
    );

    // Generate sender and recipient keypairs
    let sender = Keypair::new();
    let recipient = Keypair::new();

    // Fund sender with airdrop
    let airdrop_signature = connection
        .request_airdrop(&sender.pubkey(), LAMPORTS_PER_SOL)
        .await?;

    loop {
        let confirmed = connection.confirm_transaction(&airdrop_signature).await?;
        if confirmed {
            break;
        }
    }

    // Check balance before transfer
    let pre_balance1 = connection.get_balance(&sender.pubkey()).await?;
    let pre_balance2 = connection.get_balance(&recipient.pubkey()).await?;

    // Define the amount to transfer
    let transfer_amount = LAMPORTS_PER_SOL / 100; // 0.01 SOL

    // Create a transfer instruction for transferring SOL from sender to recipient
    let transfer_instruction =
        system_instruction::transfer(&sender.pubkey(), &recipient.pubkey(), transfer_amount);

    // Add the transfer instruction to a new transaction
    let mut transaction =
        Transaction::new_with_payer(&[transfer_instruction], Some(&sender.pubkey()));

    let blockhash = connection.get_latest_blockhash().await?;
    transaction.sign(&[&sender], blockhash);

    // Send the transaction to the network
    let transaction_signature = connection
        .send_and_confirm_transaction(&transaction)
        .await?;

    // Check balance after transfer
    let post_balance1 = connection.get_balance(&sender.pubkey()).await?;
    let post_balance2 = connection.get_balance(&recipient.pubkey()).await?;

    println!(
        "Sender prebalance: {}",
        pre_balance1 as f64 / LAMPORTS_PER_SOL as f64
    );
    println!(
        "Recipient prebalance: {}",
        pre_balance2 as f64 / LAMPORTS_PER_SOL as f64
    );
    println!(
        "Sender postbalance: {}",
        post_balance1 as f64 / LAMPORTS_PER_SOL as f64
    );
    println!(
        "Recipient postbalance: {}",
        post_balance2 as f64 / LAMPORTS_PER_SOL as f64
    );
    println!("Transaction Signature: {}", transaction_signature);

    Ok(())
}

Why SOL Is Always Required for Gas

Network Protection: Fees prevent spam and misuse of validator resources
Validator Compensation: Minimum charge is 5,000 lamports per signature. Half is burned; the other half compensates the validator for processing the transaction
Why SOL Only? Validators rely on SOL as the native, consistently valued token. Accepting other tokens would break consensus, as validators cannot universally verify their value or convert them consistently

Kora's Core Innovation

At its core, Kora is a relayer that removes the strict dependency on users to hold SOL for every transaction. Instead of forcing users to hold SOL, Kora steps in as the fee payer. Validators still get paid in SOL, but users reimburse the Kora operator in the token they already hold USDC, BONK, or any other SPL token.

The result is "gasless." Not because the fees vanish, but because the complexity of handling SOL is abstracted away from the user. From the user's perspective, they sign one transaction, in one token, and it just works.

Building on our previous SOL transfer example, let's see how Kora transforms the Solana transaction flow to eliminate the SOL requirement for end users.

Kora Transaction Flow: From Friction to Seamless

Here's how Kora handles a BONK token transfer from David to Samuel, with David paying fees in BONK rather than SOL:

User Interaction: The user interacts with a dApp that utilizes Kora
Transaction Construction: The application constructs the Solana transaction to transfer BONK from David to Samuel, and includes a token payment instruction to the Kora node operator as part of this transaction
User Authorization: The user signs their portion of the transaction using their wallet
Kora Routing: Instead of sending directly to the Solana network, the application forwards the partially signed transaction to the configured Kora RPC endpoint
Validation Process: The Kora node thoroughly validates the transaction against its configured rules defined in the kora.toml file:
- Are the included instructions valid?
- Is the SPL token payment adequate to cover current SOL fees (based on Oracle price feed)?
- Is this transaction allowed under the node's security policies (allowed programs/tokens)?
Co-signing: If valid, Kora co-signs as the fee payer, covering the actual SOL network fees and returns the signed transaction to the app
Network Submission: Application forwards the Kora-signed transaction to Solana for processing
Execution: Solana executes the transaction. The SPL tokens transfer to the Kora node operator, the actual SOL fees are paid by the Kora node, and the user's intended transaction processes
Completion: The application monitors transaction status and notifies the user upon successful completion

The user successfully completes their transaction using only SPL tokens, while Kora handles all SOL-denominated network fees behind the scenes, making the experience truly "gasless." Because Solana transactions are atomic, if the fee payment to the Kora node fails, or if any other instruction within the bundled transaction fails, the entire operation reverts. The fee conversion from SPL tokens to SOL is handled entirely by the Kora node operator, making it invisible and seamless to the end user.

sequenceDiagram
    participant User
    participant dApp
    participant KoraNode
    participant SolanaNetwork
    User->>dApp: Initiates transfer (BONK from David → Samuel)
    dApp->>dApp: Build transaction\n+ Token payment instruction to Kora node
    dApp->>User: Request signature
    User->>dApp: Signs transaction
    dApp->>KoraNode: Sends partially signed transaction
    KoraNode->>KoraNode: Validate transaction\n- Valid instructions?\nAdequate SPL token payment?\n- Allowed under policies?
    alt Transaction invalid
        KoraNode-->>dApp: Reject transaction
    else Transaction valid
        KoraNode->>dApp: Co-signs as fee payer\n(Covers SOL fees)
        dApp->>SolanaNetwork: Forwards fully signed transaction
        SolanaNetwork->>SolanaNetwork: Executes transaction\n- Transfers SPL tokens to Kora node\n- Pays SOL fees from Kora node\n- Processes user's transfer
        SolanaNetwork->>dApp: Confirmation
        dApp->>User: Notify success
    end

This flow demonstrates how Kora abstracts away the underlying complexity while maintaining the security and atomicity guarantees of Solana transactions. Now let's examine the technical architecture that makes this possible.

Kora's Technical Architecture

The seamless user experience Kora enables even though it sounds magical is not magic it is the product of a meticulously engineered system where each component plays a critical, interdependent role. This architecture is designed not just to abstract gas fees, but to do so securely, scalably, and in a way that empowers developers rather than constraining them

The Four Pillars of Kora's architecture

Rust Core Library:
this is the deterministic rulebook and execution engine for the Kora protocol, this library processes every incoming transaction to execute a series validations defined in the node's kora.toml configuration file. Its function is threefold: it first validates all transaction instructions for correctness against their associated Solana programs; it then performs a check, using a price oracle to verify the proffered SPL token fee adequately covers the network cost in SOL plus any margin; and finally, it enforces security policy by whitelisting allowed programs and tokens while blacklisting malicious accounts. This process is the critical gatekeeper, ensuring only valid transactions are co-signed, thereby protecting the node operator's SOL funds from exploitation and transforming their wallet into a secure, programmable asset.
TypeScript SDK:
The TypeScript SDK is the developer-facing gateway to the Kora protocol, providing a streamlined interface for integrating gasless transactions into applications. Its primary purpose is to abstract the underlying complexity of constructing, signing, and relaying transactions to a Kora node. The SDK handles the entire client-side workflow: it bundles the user's intended instructions with a necessary fee payment instruction to the Kora operator, manages the serialization and deserialization of transactions, and facilitates all communication with the Kora RPC server via a defined API. By offering a clean, well-documented API with comprehensive code examples for common actions like token transfers and swaps, it allows developers to implement a gasless user experience with minimal code, focusing on their application logic rather than the low-level intricacies of transaction management.
JSON-RPC Server:
The JSON-RPC Server operates as the central hub for the Kora network, providing the primary interface that applications use to access its gasless functionality. This server delivers a standardized HTTP API which runs on http://localhost:8080 by default, enabling consistent communication regardless of the client's programming language. It exposes several critical endpoints that manage the gasless transaction lifecycle:
- estimate_transaction_fee: This endpoint allows applications to calculate the exact cost of a transaction before it is submitted. A client provides a simulation of the transaction, and the server returns a quote denominated in the user's chosen SPL token. This quote is calculated using a price oracle to convert the network fee (in SOL) into the equivalent amount of the specified token, including any margin configured by the node operator. This provides essential cost certainty for the end-user.
- get_supported_tokens: This method returns a list of token mints that the node operator has configured as acceptable forms of payment for transaction fees. This list is defined in the kora.toml file under allowed_spl_paid_tokens. Applications can call this endpoint to dynamically populate a UI, showing users which tokens they can use to pay for gas on that particular node.
- sign_and_send_transaction: This is the primary endpoint for processing gasless transactions. A client submits a partially-signed transaction bundle that includes both the user's intended instructions and a fee payment instruction. The server performs several actions: it validates the request, delegates the transaction to the core library for security and economic checks, appends the node's signature as the fee payer if validation passes, and finally submits the fully-signed transaction to the Solana network. It then returns the resulting transaction signature to the client for confirmation.
CLI Tool:
The CLI Tool is the operational control panel for the node operator, providing the necessary commands to deploy, configure, and monitor a Kora node. Its purpose is to grant the operator direct management capabilities over the node's behavior and health outside of the real-time transaction flow. This tool is used to edit the kora.toml configuration file defining security policies, economic parameters, and authentication secrets—and to start the service with specific runtime flags. It also provides commands for real-time monitoring of node status, checking signer wallet balances, and viewing logs for debugging. By offering a direct command line interface, the CLI ensures that node operators, particularly DevOps and infrastructure teams, have the precise control required to maintain a secure, efficient, and profitable Kora service in a production environment

With the four pillars of the architecture establishing how a transaction is processed, the next critical consideration is who authorizes the payment of SOL and how that authority is secured. This brings us to the core of operational security.

Signer Options

1. Solana Private Key (Self-Managed)

Best for: Development environments and small-scale deployments
Setup Options:
- Environment variables
- CLI flags
- JSON file path
Supported Formats:
- Base58 (default)
- U8Array
- JSON file
Generate New Keypair: Use Solana CLI tools

2. Turnkey Integration (Enterprise)

Best for: Production deployments requiring maximum security
Benefits: Hardware Security Modules (HSMs) and granular policy controls
Requirements:
- Turnkey account setup
- Environment variables: Organization ID, API keys, Private Key ID
- Start with --with-turnkey-signer flag

3. Privy Integration (Web3 Apps)

Best for: Applications with embedded wallet infrastructure
Requirements:
- Privy account configuration
- Environment variables: App ID, App Secret, Wallet ID
- Start with --with-privy-signer flag

The choice of signer integration directly impacts both security posture and operational complexity. Enterprise deployments should prioritize HSM-backed solutions, while development environments can use simpler key management approaches. However, regardless of the signer chosen, proper authentication is essential to prevent unauthorized access.

Authentication: Securing Your RPC Endpoint

Without authentication, anyone who discovers your endpoint can submit transactions and drain your SOL balance. Kora provides two complementary authentication methods that can be used individually or combined for maximum security.

Method 1: API Key Authentication

How it Works: Simple shared secret transmitted in HTTP headers
Setup Process:
- Add API key to .env file or kora.toml configuration
- Clients include key in x-api-key header with every request
Security Level: Basic protection suitable for internal applications or trusted clients
Risk Consideration: If intercepted, acts like a password that grants full access

Method 2: HMAC Authentication

How it Works: Creates unique cryptographic signature for each request
Setup Process:
- Add KORA_HMAC_SECRET (minimum 32 characters) to configuration
- Client Process:
- Combine {timestamp}{request_body}
- Sign with HMAC-SHA256 using shared secret
- Send headers: x-timestamp and x-hmac-signature
- Server Validation: Validates signature and timestamp with 5-minute expiry window
Security Level: High-grade protection suitable for public APIs or untrusted networks
Key Benefit: Secret never travels over the network, preventing interception attacks

For production deployments, we recommend enabling both authentication methods simultaneously. This layered approach provides defense in depth, ensuring that even if one authentication method is compromised, the secondary method provides continued protection.

Now that we've covered security fundamentals, let's examine how to configure Kora nodes to meet specific business requirements and operational constraints.

Configuration Management

The kora.toml file serves as the control center for a Kora node's behavior, allowing operators to define business requirements and security policies for transaction processing. It should be located in the deployment directory or specified via the --config flag when starting the server.

Key Configuration Sections

Kora Core Policies

Configures fundamental server behavior including rate limiting (requests per second) and global authentication policies for api_key and hmac_secret. These settings form the baseline security and performance profile for your node.

Kora Enabled Methods

Controls which RPC methods (e.g., sign_transaction, get_supported_tokens) are enabled or disabled. By default, all methods are enabled unless this section is explicitly configured, giving operators granular control over node functionality.

Validation Policies

Defines Solana-related security rules and transaction limits:

max_allowed_lamports: Limits the maximum SOL amount a Kora node will pay per transaction, providing crucial cost controls
max_signatures: Sets the maximum number of signatures per transaction to prevent excessive SOL spending on complex transactions
price_source: Specifies the oracle for token price data—"Jupiter" for production environments or "Mock" for testing scenarios
allowed_programs: Whitelists Solana programs that transactions can interact with, creating a secure "walled garden" environment
allowed_tokens and allowed_spl_paid_tokens: Whitelist token mints that can be used in transactions or accepted as payment for fees
disallowed_accounts: Blacklists accounts explicitly blocked from all transactions

Fee Payer Policy

Restricts what the Kora node's fee payer wallet can do, preventing unexpected behavior or unauthorized transfers. Security best practice recommends setting all options (like allow_sol_transfers, allow_spl_transfers) to false by default and enabling only as specifically needed.

Price Configuration

Defines how transaction fees are calculated, offering three distinct business models:

Margin Pricing: Adds a percentage margin on top of actual network fees (default margin is 0.0%). This ensures SOL costs are covered while generating profit margins for node operators.
Fixed Pricing: Charges a fixed amount in a specific token regardless of fluctuating network fees. This provides predictable costs for users but transfers fee volatility risk to node operators.
Free Pricing: Sponsors all transaction fees, charging nothing to users. This powerful tool for user acquisition and growth is often used for subsidized onboarding campaigns.

These configuration options provide the flexibility to adapt Kora nodes to different business models, from profit-generating services to user acquisition tools. With configuration covered, let's move to practical implementation with a comprehensive setup guide.

Getting Started with Kora

To begin developing with Kora, you'll establish a local development environment. This involves installing the Kora RPC server, configuring it to accept SPL token payments, and running a client demonstration to witness fee abstraction in action.

Prerequisites

Solana CLI v2.2.x or newer
Rust programming environment
Node.js v24 or later

Step 1: Install the Kora RPC Server

cargo install kora-rpc

This installation provides the `kora-rpc` binary that serves as your local Kora node for development and testing purposes.

Step 2: Clone the Demo Project

git clone https://github.com/solana-foundation/kora.git
cd kora/demo

Understanding the Demo Structure:

client/src/
- setup.ts – Local environment initialization, including generating keypairs, airdropping SOL, and initializing test tokens
- main.ts – Runs the demonstration transaction using token-based fees
- client.ts – Kora client factory for RPC communication
- types.ts – TypeScript definitions for Kora RPC request/response types
server/
- kora.toml – Kora node configuration defining security rules, allowed tokens, and fee parameters
demo/.env – Created by setup.ts, containing keypairs and mint addresses

Step 3: Install Client Dependencies

cd client
npm install
cd ..

Step 4: Initialize the Local Environment

Run the setup script to prepare your development environment:

npm tsx client/src/setup.ts

This initialization process will:

Generate development keypairs and write them to demo/.env
Airdrop SOL to test accounts (for local validator compatibility)
Create a USDC test token mint and fund test accounts
Display the USDC mint public key for configuration

**Important:** Copy the USDC mint address from the output; you'll need it for the next configuration step.

Step 5: Configure kora.toml

Open `server/kora.toml` and whitelist your test token so Kora accepts it as a payment method. In the `[validation]` section, configure:

# Replace with your actual USDC mint from setup output
allowed_tokens = ["<USDC_TOKEN_MINT_PUBKEY>"]
allowed_spl_paid_tokens = ["<USDC_TOKEN_MINT_PUBKEY>"]

Additional Configuration Options (adjust as needed):

max_allowed_lamports – Cap the SOL your node will sponsor per transaction
max_signatures – Limit Solana base-fee exposure (fees scale with signature count)
price_source – Token pricing source ("Mock" for local development, "Jupiter" for production)
allowed_programs – Whitelist program IDs users can invoke
disallowed_accounts – Explicit account blocklist
api_key, hmac_secret – Enable authentication (strongly recommended for production)

**Note:** If you re-run setup.ts later with a new mint, remember to update kora.toml accordingly.

Step 6: Start Services (Multi-Terminal Setup)

You'll need four terminals to run the complete demo environment:

Terminal 1: Start Local Test Validator

# From project root or anywhere
solana-test-validator -r

Terminal 2: Initialize Environment

# From ./client directory
npm init-env

This script performs several critical setup tasks:

Generate keypairs and save them to .env
Airdrop SOL to test accounts for transaction fees
Create and initialize a local USDC token
Fund test accounts with both SOL and tokens

**Important Configuration Update:** Copy the public key of the newly created USDC test token from your .env file and update both `allowed_tokens` and `allowed_spl_paid_tokens` in `./server/kora.toml`:

allowed_tokens = [
    "YOUR_USDC_LOCAL_PUBLIC_KEY" # Update with USDC_LOCAL_KEY public key from .env
]
allowed_spl_paid_tokens = [
    "YOUR_USDC_LOCAL_PUBLIC_KEY" # Update with USDC_LOCAL_KEY public key from .env
]

Terminal 3: Start Kora RPC Server

# From ./server directory
kora-rpc

The server reads configuration from kora.toml and uses environment variables from the shared .env file. If using different folder structures, you may need the `--config` flag to specify kora.toml location and `--private-key` to specify your private key directory. Use `kora-rpc -h` for comprehensive help.

Terminal 4: Run Client Demo

# From ./client directory
npm start

Expected Output:

Kora Config: {
    fee_payer: 'Df2UmGQH86TBDsub7XZoSAo7KZa1ZJZr2w1PL1APUjjU',
    validation_config: {
        max_allowed_lamports: 1000000,
        max_signatures: 10,
        allowed_programs: [
            '11111111111111111111111111111111',
            'TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA',
            'ATokenGPvbdGVxr1b2hvZbsiqW5xWH25efTNsLJA8knL'
        ],
        allowed_tokens: [
            'usdCAEFbouFGxdkbHCRtMTcN7DJHd3aCmP9vqjLgmAp'
        ],
        allowed_spl_paid_tokens: [
            'usdCAEFbouFGxdkbHCRtMTcN7DJHd3aCmP9vqjLgmAp'
        ],
        disallowed_accounts: [],
        price_source: 'Mock'
    }
}
Blockhash: C8W8d5w2H4jKXyFg5CEBoiaPvEpJ1am7xLxZ3fym4a2g

This output confirms your Kora server is running and properly configured for development. You're now ready to experience gasless transactions firsthand and begin building applications that leverage Kora's fee abstraction capabilities.

With your development environment established, the next consideration is how to scale and secure these capabilities for production deployment.

Production Deployment and Infrastructure Management

Operating a Kora node requires a strategic approach to deployment and robust infrastructure management. As a paymaster service handling user transactions and managing significant SOL funds, infrastructure choices and operational practices are paramount to success.

Deployment Options: Self-Host vs. Cloud

Kora offers flexible deployment across various environments to match different operational requirements and technical constraints.

Local Development:

Run Kora nodes locally for rapid testing and development iteration. This approach provides full control and immediate feedback during the development process.

Production Environments:

Kora supports deployment via Docker containers or direct installation on any cloud platform. The kora-rpc crate is distributed as a standalone executable that can be installed globally or deployed in containerized environments.

Railway Integration:

Railway provides streamlined deployment experience for Kora nodes, including automatic SSL certificate management, domain configuration, and built-in monitoring capabilities. This managed approach reduces operational overhead while maintaining security standards.

Scaling Considerations

Traffic Management:

Kora allows node operators to implement global, per-second rate limiting configurable via the rate_limit option in kora.toml. This prevents abuse and ensures consistent performance under varying load conditions.

Capacity Planning:

Node operators must plan for expected use cases and user volume. Consider factors like peak transaction times, seasonal usage patterns, and growth projections when sizing infrastructure.

RPC Endpoint Strategy:

Kora requires a Solana RPC endpoint specified via the --rpc-url flag or RPC_URL environment variable. For higher transaction volumes, external scalable RPC services can handle increased demand while maintaining performance standards. These infrastructure considerations directly impact security requirements, which represent the most critical aspect of production Kora node operations.

Security Best Practices

Security is paramount for Kora node operators, as the node's signer key has direct access to SOL funds used for fee payments. Kora provides multiple layers of protection to safeguard operations and user funds.

Authentication Security

Dual Authentication Approach:

Kora supports two optional authentication methods that can be used individually or combined for maximum protection:

API Key Authentication: Basic security using shared secrets in HTTP headers via x-api-key. Suitable for internal applications or trusted clients, but vulnerable if intercepted.
HMAC Authentication: Advanced security creating unique cryptographic signatures for each request. Each signature includes timestamps that expire after 5 minutes, preventing replay attacks. Attackers cannot create valid requests without the shared secret key.
Combined Authentication: For maximum security, both methods can be enabled simultaneously, requiring clients to provide x-api-key, x-timestamp, and x-hmac-signature headers.

Signer Key Security

The signer keypair controls your SOL funds and requires the highest level of protection:

Operational Security Practices:

Dedicated Keypairs: Use keypairs exclusively for your Kora node, avoiding reuse of personal wallets
Minimal Funding: Only fund signer wallets with SOL amounts you're prepared to spend on transaction fees
Secure Storage: Never hardcode private keys or API keys in source code or logs. Use environment variables or dedicated secrets management systems
Regular Rotation: Rotate authentication keys periodically (monthly or quarterly schedules)

Enterprise Key Management:

For production-grade applications, Kora integrates with enterprise key management services:

Turnkey Integration: Provides Hardware Security Modules (HSMs) and policy controls for maximum security
Privy Integration: Offers embedded wallet infrastructure with institutional-grade protection

Monitoring and Alerting: Implement comprehensive monitoring for:

Low SOL balance alerts to prevent service interruption
Unusual transaction patterns that might indicate compromise
Authentication failures and security events

These security measures provide the foundation for reliable, secure Kora node operations. However, understanding the broader impact and applications of this technology reveals why Kora represents a fundamental shift in blockchain user experience.

Real-World Impact: Emerging Markets

In regions like Africa, where blockchain adoption is accelerating rapidly, Kora's fee abstraction becomes even more transformative. Consider these scenarios where Kora can deliver immediate impact:

Mobile Money Integration: In countries like Sierra Leone, Nigeria, and Kenya, where mobile money dominates financial transactions, users are already comfortable with digital payments. Kora enables seamless bridges between local mobile money systems and Solana dApps, allowing users to pay transaction fees with familiar stablecoin equivalents without ever touching SOL.

Remittances and Cross-Border Payments: Family members sending money across African borders can use stablecoin-powered applications that leverage Kora for gasless transactions. Recipients can receive and transact immediately without needing to acquire SOL first—a crucial advantage in regions where cryptocurrency exchanges may be limited or expensive.

Merchant Adoption: Small businesses and market vendors can accept cryptocurrency payments through Kora-powered point-of-sale systems, with transaction fees handled transparently in the background using the same currency they're receiving as payment.

Building the Future

Whether you're developing stablecoin-first applications for emerging markets, building gaming experiences that need frictionless microtransactions, or creating any dApp where user experience supersedes technical complexity, Kora provides the infrastructure to make "gasless" transactions a reality.

The future of blockchain adoption lies not in asking users to understand our technical constraints, but in building infrastructure that adapts to their needs. With Kora, that future begins now.

Ready to Start Building?

Explore the GitHub repository: github.com/solana-foundation/kora

Friction to Flow

Mitch — Tue, 09 Sep 2025 13:59:00 +0000

If you've spent any time building on Solana, you know the rhythm of the local development loop. It often involves a lot of friction: waiting for solana-test-validator to spin up, writing one-off scripts to deploy and initialise programs, and struggling to recreate the complex state of main-net accounts you need to interact with. The feedback loop can feel slow, and the setup overhead for each new feature can be a real drag on momentum.

I'd gotten used to this friction, accepting it as the cost of building on a high-performance chain. Then I came across Surfpool, and my perspective shifted. It wasn't just another local validator; it was a suite of integrated tools that attacked these friction points in surprisingly powerful ways. After a few weeks of use, my entire workflow feels different—faster, smoother, and more intuitive. This article is my way of sharing the six most impactful features that have fundamentally changed how I develop on Solana.

The Listicle: 6 Game-Changing Features

You Can Test Against Mainnet State Without Leaving Your Laptop

Surfpool's local simulator, called a surfnet, has a killer feature: live mainnet forking. When you run a local surfnet, any transaction or query that references an account not found in your local state is automatically fetched from the public mainnet on the fly. This means you can interact with any mainnet program—be it a major DeFi protocol or a simple SPL token mint—without having to manually script its deployment or download its state beforehand.

This is a complete game-changer for integration testing, especially for programs that make CPIs to other mainnet protocols. The old way meant dealing with a local validator that was completely ignorant of mainnet state—a query against a mainnet account would simply fail. Your only recourse was to write tedious scripts to create mock accounts. With Surfpool, that entire category of friction is gone. The external accounts you need are just there, with their correct state, exactly when you need them.

You Can Time Travel and Get an X-Ray of Your Transactions

Every running surfnet comes with Surfpool Studio, a local web UI that acts as a mission control for your development environment. Two features here stand out. The first is "time travel," which lets you instantly jump the network's clock forward by a specific number of days, slots, or even to the next epoch with a single click. The second is a powerful transaction inspector. It doesn't just show you the transaction logs; it gives you a per-instruction breakdown of compute unit usage and provides detailed before-and-after state diffs for every affected account. If you've deployed your program with Surfpool, it even uses your program's IDL to parse and show diffs for your custom account data.

The ability to manipulate time is invaluable for testing any on-chain logic that's dependent on slots or epochs, eliminating long waits from your feedback loop. The granular detail from the transaction inspector provides an unparalleled level of insight. Debugging becomes incredibly efficient when you can see exactly which instruction is consuming the most CUs or watch the supply field of an SPL Token account change in a perfectly parsed state diff.

You Get a Free GraphQL API the Moment You Deploy

When you deploy a program using surfpool start, Surfpool can automatically create a subgraph for you. This is essentially a ready-to-use GraphQL database that listens to your surfnet, indexes the events your program emits, and makes them available through a queryable API. The schema is automatically generated from your program's event struct, giving you an indexed backend that is available "right out of the box."

...we've got a GraphQL database just ready to go and query of every time our program is invoked, and Surf Pool is just giving us that right out of the box. Right when you deploy your program, you've got that ready to go.

This feature is a massive accelerator for full-stack development. It completely removes the need to set up, configure, and manage a separate indexer and database to power your dApp's frontend. You can move directly from writing your on-chain logic to building your UI, knowing the data layer is already handled.

You Can Give Yourself Any Mainnet Token on Demand

Surfpool includes "Cheatcode RPC methods" that allow you to directly modify the state of your local surfnet. This power is exposed through an easy-to-use web faucet. With a few clicks, you can instantly fund any of your local wallets with SOL or even any mainnet SPL token, like USDC. There's no need to write custom airdrop scripts or deploy mock token mints; you just tell the faucet what you want, and it appears in your wallet.

This simple utility removes a significant amount of tedious setup work. Testing applications that interact with various tokens, especially in DeFi, often requires a complex matrix of wallets holding different assets. Surfpool's faucet turns this multi-step scripting process into a few seconds of clicking in a web UI.

Your Local Deployment Script is Your Mainnet Deployment Script

Surfpool is built around an Infrastructure as Code (IaC) system that uses declarative files called "Runbooks." When you first run surfpool start in your program's directory, it automatically generates these runbooks for you. The most powerful part of this system is that the exact same runbook file used to deploy to your local surfnet can be used to deploy to devnet and mainnet. The only thing you need to change is the target environment in your txtx.yml manifest file, which allows you to swap out environment-specific configurations, such as replacing a local secret key signer with a production-grade multisig signer like Squads.

This creates a level of deployment consistency and reliability that's often missing in Web3 workflows. By using the same declarative script across all environments, you eliminate the entire class of "it worked on my machine" bugs. You can develop and test with high confidence, knowing that your main-net deployment will follow the exact same, battle-tested steps as your local one.

You Can Literally Talk to Your Local Blockchain

The Surfpool MCP (Meta-Command Palette) feature allows you to integrate your development environment with AI chat assistants like GitHub Copilot or Cursor. Once configured, you can open your AI chat and give it natural language commands. For example, you can type "start a surfnet and fund an account with 100 SOL" and watch as Surfpool executes the commands. You can also ask it questions about your network's state, like "what is the token account balance for USDC?", and the AI will use the appropriate RPC calls on your surfnet to find and return the answer.

This feature radically lowers the barrier to entry for common development tasks. Instead of hunting for specific CLI flags or memorising RPC method names, you can simply state your intent. It streamlines the setup and query process, keeping you focused on the code you're actually trying to write.

Conclusion: A New Baseline for Solana DX

After using these features, it's clear that Surfpool isn't just a local validator replacement; it's an integrated development environment designed to accelerate the entire build-test-deploy lifecycle. By systematically identifying and removing sources of friction—from mainnet simulation and state inspection to deployment automation and data indexing—it establishes a new baseline for what a great developer experience on Solana can be. It lets you spend less time on tedious overhead and more time building.

With tools this powerful abstracting away development overhead, what new kinds of complex applications will we be empowered to build?

The $3 That Broke Crypto UX (And How Kora Fixed It)

Mitch — Mon, 01 Sep 2025 16:11:54 +0000

Two years ago, I walked into my first crypto event with zero knowledge on crypto. When the presenter asked a question, I raised my hand. Boom $3 straight to my wallet for a correct answer. I was genuinely excited. Real digital money I could actually spend, right? Wrong. What followed was a painful lesson in crypto's biggest UX flaw: I needed to buy a completely different token just to move the money I'd earned. Standing there confused, holding dollars I couldn't spend without SOL I didn't have, I thought exactly what millions of first-time users think: this whole thing is a scam.

That frustration stuck with me. Not because I'm bitter about three dollars, but because I realised this broken experience is repeated thousands of times daily across the ecosystem. Kora is built to remove that friction. The issue is every time you want to do anything on Solana send tokens, trade, interact with apps you need SOL to pay for it. This creates a chicken-and-egg problem: you've earned some USDC or BONK tokens, but you can't use them without first getting SOL.

Why does this happen?

Network Protection: Small fees prevent spam and keep the network running smoothly
Paying Validators: The computers that process transactions need compensation
System Stability: SOL has a stable value that everyone agrees on

While these reasons make technical sense, they create a terrible experience for new users.

Kora's Solution: Pay Fees with Any Token

Kora solves this by acting as a middleman. Instead of forcing you to get SOL first, Kora pays the SOL fees for you, and you pay Kora back using whatever tokens you already have - USDC, BONK, or any other token.

How It Works: Before and After

Let's see the difference between traditional transactions on Solana vs Kora transactions:

Step	Traditional Way (With SOL)	Kora Way (Gasless)
1	User must first buy SOL	User starts with any token (BONK, USDC, etc.)
2	User creates transaction	App creates transaction + fee payment to Kora
3	User pays SOL fees directly	User signs transaction (no SOL needed)
4	Transaction goes to Solana network	Kora validates and co-signs with SOL
5	Network processes transaction	Network processes: user's action + Kora gets tokens
Result	User needed SOL upfront	User paid fees in tokens they already had

The key insight: both transactions cost the same SOL fees, but with Kora, the user never has to handle SOL directly. Kora makes this powerful through four main parts

Rust Core Library: This component functions as the core transaction verification engine. It ensures transaction integrity, computes user-specific token costs based on their selected currency, and enforces protocol compliance.
TypeScript SDK: This suite provides application developers with streamlined integration of gasless transactions. It abstracts the complexity of building custom infrastructure, allowing developers to leverage Kora's simplified tools.
JSON-RPC Server: This module acts as an intermediary, facilitating communication between applications and the Kora network. It manages queries related to transaction cost estimation in specified tokens (e.g., USDC) and processes gasless transaction requests.
CLI Tool: Designed for Kora operators, this interface enables service management, including policy configuration, performance monitoring, and operational oversight.

Use Cases

Kora isn't just about solving the gas problem it opens up entirely new possibilities for how people can interact with blockchain applications:

Mobile Money Integration: In countries like Sierra Leone, Nigeria, and Ghana where mobile money dominates, users can seamlessly bridge from their familiar mobile money solutions or similar systems to Solana dApps using stablecoin equivalents.
Remittances: Family members sending money across borders can use stablecoin applications where recipients immediately transact without needing to acquire SOL - crucial in regions with limited crypto exchange access.
Merchant Payments: Small businesses can accept cryptocurrency payments through point-of-sale systems where transaction fees are handled transparently in the background.
Creator Economy: Content creators earning tokens from tips, subscriptions, or sales can immediately reinvest in their creative tools, collaborate with others, or support fellow creators.
Yield Farming: Users earning rewards from liquidity pools can immediately compound their earnings or move funds between protocols without keeping a SOL buffer.
Automated Strategies: DeFi applications can offer truly automated yield strategies where users never need to worry about maintaining SOL balances for transaction fees.
Cross-Protocol Trading: Traders can seamlessly move between different DeFi protocols using their trading profits to pay fees, enabling more sophisticated strategies
Micro-lending: Users can participate in decentralized lending protocols using their earned tokens directly, without the barrier of SOL acquisition preventing participation.
DAO Participation: Community members can vote, propose, and participate in governance using tokens they earned through contribution, without SOL blocking their engagement.
Social Tokens: Creators and communities can build token-based social platforms where followers can tip, purchase access, or buy exclusive content using social tokens directly.
Crowdfunding: Project supporters can immediately use funds raised in one campaign to support other projects they believe in, creating vibrant funding ecosystems.
Supply Chain Management: Companies can track products and payments across supply chains using earned tokens for transaction fees, simplifying multi-party business processes.
Payroll Systems: Organizations paying employees in tokens can enable those employees to immediately use their earnings for expenses, investments, or other transactions.
Loyalty Programs: Businesses can create sophisticated loyalty systems where customers earn tokens and immediately redeem them across partner merchants without friction.

Integrating Kora

To add gasless transactions to your applications, you can integrate with Kora in three main ways:

Using Existing Kora Services: Many developers simply connect to existing Kora nodes operated by service providers. This is like using a payment processor - you integrate once and get immediate gasless functionality.
Running your Own Node: Some applications prefer complete control and run their own Kora infrastructure. This gives them full control over policies, costs, and user experience.
Hybrid Approach: Larger applications might run their own nodes for core functionality while using third-party services for overflow or specific use cases.

What is a Kora Node?

A Kora node is essentially a specialized server that acts as a bridge between users and the Solana network.

It holds SOL to pay network fees
It accepts other tokens as payment from users
It validates transactions to ensure they're safe and legitimate
It co-signs transactions to authorize the SOL payment
It enforces policies to protect itself and its users

The node operates 24/7, automatically processing gasless transaction requests according to its configured rules.

Who Are Node Operators?

Node operators are the people or organizations that run and maintain Kora nodes. Running a Kora node involves several important considerations that affect both profitability and security:

Economic Considerations

Fee Structure: Operators must decide how to price their services - charging a margin on top of network fees, setting fixed prices, or even offering free transactions to attract users.
Token Risk: Since operators accept various tokens as payment, they're exposed to price volatility. A token's value might drop between when they receive it and when they convert it to SOL.
Capital Requirements: Operators need sufficient SOL reserves to handle transaction volume during busy periods, plus backup funds for unexpected spikes.

Security Imperatives

Access Control: Operators must carefully control who can use their service. Kora provides API key and HMAC authentication methods that can be used separately or together for maximum protection.
Transaction Validation: Operators can set strict rules about which transactions they'll process - limiting SOL amounts, restricting allowed programs, whitelisting specific tokens, and blacklisting suspicious accounts.
Key Management: The private keys controlling SOL funds need enterprise-grade protection. Kora integrates with professional services like Turnkey (hardware security modules) and Privy (institutional wallet infrastructure) for serious operations.

Operational Considerations

Monitoring and Alerting: Operators need systems to track SOL balances, unusual transaction patterns, authentication failures, and performance metrics to ensure smooth operation.
Compliance and Policies: Depending on their jurisdiction and customer base, operators may need to implement compliance measures, transaction limits, and user verification processes.
Scalability Planning: As usage grows, operators need to plan for increased transaction volume, higher SOL requirements, and potentially distributed infrastructure.

Running Kora Locally

Ready to try gasless transactions? Setting up a development environment is straightforward:

Prerequisites

Solana CLI v2.2.x or newer
Rust programming environment
Node.js v24 or later

Quick Setup

# Install Kora RPC server
cargo install kora-rpc

# Clone demo project
git clone https://github.com/solana-foundation/kora.git
cd kora/demo

# Install dependencies and initialize
cd client && npm install && cd ..
npm tsx client/src/setup.ts

The setup script generates keypairs, creates test tokens, and displays configuration details. Update server/kora.toml with your test token mint address, then start the services:

# Terminal 1: Start validator
solana-test-validator -r

# Terminal 2: Start Kora RPC
kora-rpc

# Terminal 3: Run demo
npm start

Building the Future

Kora represents more than technical advancement - it's infrastructure for true financial inclusion. By removing the complexity of native token requirements, Kora provides the foundation for accessible user experiences that rival traditional applications.

The future of blockchain adoption lies not in asking users to understand our technical constraints, but in building infrastructure that adapts to their needs. Whether you're developing stablecoin-first applications for emerging markets, building gaming experiences with frictionless microtransactions, or creating any dApp where user experience supersedes technical complexity, Kora makes it possible.

With Kora, that future begins now.

Ready to start building?

Explore Kora now: github.com/solana-foundation/kora

Solana's Bridge Between Web2 and Web3

Mitch — Tue, 06 May 2025 18:26:12 +0000

The latest Agave release Agave 2.2 introduces support for secp256r1 signatures. While this might sound like technical jargon, this addition has significant implications for Solana's ecosystem, from everyday users to developers and enterprises. In this article, we'll explore what secp256r1 signatures are, why they matter for Solana, and how they are positioned to shape the future of blockchain interactions.

What's the Big Deal About `Secp256r1` Signatures?

At its core, the addition of native secp256r1 signature verification to Solana is about making blockchain technology more accessible, secure, and compatible with existing web standards. As described in this TLDR Agave 2.2 article by Helius

"Solana is adding native support for secp256r1 elliptic curve signature verification, a critical upgrade that enables on-chain compatibility with Passkeys, the WebAuthn standard, and advanced account abstraction models, including two-factor authentication (2FA). This update introduces passwordless authentication, already ubiquitous in Web2, into the Web3 domain, enhancing security and usability for on-chain applications."

But what does all this actually mean? Let's break it down.

Digital Signatures 101: The Basics

Think of a digital signature as the blockchain equivalent of your handwritten signature but significantly more secure and mathematically verifiable. When you make a transaction on Solana (or any blockchain), you need to prove it's really you initiating that action.

Digital signatures work through a pair of cryptographic keys:

A private key that only you have (like your unique signature)
A public key that everyone can see (like your ID card)

When you sign a transaction, your private key creates a unique signature that can be verified using your public key. This verification happens through complex mathematical operations on what's called an "elliptic curve."

What Makes `Secp256r1` Special?

Solana has primarily used the Ed25519 signature scheme for its core cryptographic operations, while Solana also supports secp256k1-mainly to enable interoperability and bridging with Bitcoin and Ethereum, which both use the secp256k1 curve; Ed25519 remains the default for signing standard transactions on the Solana network. With the Agave 2.2 update, Solana is adding native support for secp256r1 (also known as NIST P-256 or prime256v1).

But what’s the difference, and why is this important?

Secp256r1 is widely adopted outside the blockchain world. It’s the standard elliptic curve used in:

Web browsers for secure connections
Hardware security keys like YubiKeys
The WebAuthn standard for passwordless authentication
Traditional banking and financial systems

By supporting secp256r1, Solana can now interact seamlessly with these systems. This shift is particularly relevant for cross-chain interactions, regulatory compliance, and a big step toward bridging the gap between traditional web applications (Web2) and decentralised blockchain applications (Web3).

📊 secp256r1 vs ed25519 vs secp256k1

Curve	Used In	Security Level	Standardization	Typical Use Cases
secp256r1	WebAuthn, Passkeys, HSMs, Solana	128-bit	NIST, FIDO	Web2 auth, hardware keys, enterprise
ed25519	Solana native, modern blockchains	128-bit	IETF	Solana, Signal, SSH
secp256k1	Bitcoin, Ethereum, EVM chains	128-bit	SECG	Crypto wallets, blockchains

What this could potentionally mean for YOU

The introduction of secp256r1 signatures could bring several immediate benefits including:

Passwordless Authentication : Remember how you can now log into many websites just by using your fingerprint or face ID instead of typing a password? That's WebAuthn in action. With secp256r1 support, Solana applications can now implement the same smooth experience.
Better Hardware Compatibility: Many devices we use daily have special security hardware that already supports Secp256r1, by supporting Secp256r1, Solana can more directly integrate with these security features, potentially making wallet apps more secure and user-friendly./
- Secure Enclaves: The security chips in iPhones, Macs, and many Android devices
- Hardware Security Modules (HSMs): Specialised security devices used by businesses
- TPMs (Trusted Platform Modules): Security chips built into modern computers
- Smart Cards: Including many hardware wallets and secure ID cards
Two-Factor Authentication (2FA) : The update enables more sophisticated account security models, including familiar two-factor authentication systems similar to those used by banks and email providers.
Advanced Account Abstraction : This technical term simply means more flexibility in how accounts work. Instead of being limited to a single private key, accounts can now implement more complex authorisation schemes, including multi-signature requirements and time-locked transactions.
Institutional and Enterprise Adoption : Many large organisations and government entities require systems to use NIST-approved cryptography like secp256r1:
- Banks and financial institutions often have compliance requirements specifying NIST curves
- Government agencies typically mandate NIST-approved cryptography
- Enterprise security infrastructure is frequently built around these standards.
Bridging Web2 and Web3 : Most internet security (the "Web2" world) uses secp256r1:
- SSL/TLS certificates that secure websites
- Many authentication systems and security protocols
- Public Key Infrastructure (PKI) that secures much of the internet
- Supporting the same cryptographic standards makes it easier to build applications that bridge traditional web systems and Solana's blockchain

The Technical Corner: For Those Who Want More Detail

Mathematical Foundations of `secp256r1`

At its core, secp256r1 is defined by a specific set of domain parameters over a prime finite field. The curve equation is:

$$
y^2 = x^3 + ax + b
$$

where $a$ and $b$ are constants that define the curve's shape, and all operations are performed modulo a large prime $p$. For secp256r1, the parameters are:

$p = 2^{256} - 2^{224} + 2^{192} + 2^{96} - 1$
$a = p - 3$
$b = 0x5AC635D8AA3A93E7B3EBBD55769886BC651D06B0CC53B0F63BCE3C3E27D2604B$
$G$ (generator point): a predefined point on the curve with known coordinates
$n$: the order of the subgroup generated by $G$
$h$: the cofactor, which is 1 for secp256r1

The secp256r1 curve is classified as a "random" curve, meaning its parameters were generated through a process intended to avoid any hidden weaknesses or backdoors. This distinguishes it from "Koblitz" curves, such as secp256k1, whose parameters are derived mathematically rather than randomly. Both curves are considered secure against known attacks, with their primary vulnerability being advances in quantum computing, which threaten all currently deployed public-key cryptosystems.

Secp256r1 and secp256k1 offer comparable security levels for equivalent key sizes. However, secp256r1 enjoys broader institutional support and is mandated by many regulatory frameworks, while secp256k1 is favored in cryptocurrency applications for its computational simplicity and historical association with Bitcoin and Ethereum.

Key Generation

The Elliptic Curve Digital Signature Algorithm (ECDSA) is the most common signature scheme used with secp256r1.
The key generation process involves selecting a random private key $d$ and computing the corresponding public key $Q = dG$ , where $G$ is the curve's generator point.

Signing Process

To sign a message, the signer hashes the message using a cryptographic hash function (commonly SHA-256), selects a random nonce $k$, and computes a signature pair $(r, s)$ based on the curve parameters, the private key, and the message hash. The security of the signature relies on the unpredictability of $k$ and the difficulty of the ECDLP.

Verification Process

The verifier, using the signer's public key and the signature pair, performs a series of elliptic curve operations to confirm that the signature is valid for the given message. If the computations yield the expected result, the signature is accepted; otherwise, it is rejected.

Implementation Timeline and Current Status

The secp256r1 signature verification feature was originally slated for the Agave 2.1 release but was deferred to Agave 2.2. The feature is now live and available for developers to integrate into their applications.

According to crates.io, the solana-secp256r1-program has seen multiple stable releases in 2025, with the most recent versions being:

2.2.2 (March 26, 2025)
2.2.1 (February 12, 2025)
2.1.21 (April 18, 2025)

The implementation is Apache-2.0 licensed, relatively lightweight (33KB, 583 lines of code), and has been downloaded approximately 169,966 times per month, indicating strong developer interest and adoption.

Practical Applications: What Can Be Built With This?

With secp256r1 signature verification now available in Solana, several exciting use cases become possible:

Cross-Chain Transactions

One of the most compelling use cases for secp256r1 in Solana is enabling secure cross-chain transactions. Many external systems, including enterprise blockchains and traditional financial networks, rely on secp256r1for digital signatures. By supporting this curve, Solana can facilitate seamless asset transfers and data exchange across disparate platforms.
Regulatory Compliance

Financial institutions and regulated entities often require cryptographic primitives that conform to NIST standards. secp256r1's status as a NIST-approved curve makes it an attractive option for organizations seeking to build compliant applications on Solana.
Hardware Security Modules (HSMs) and Secure Enclaves

Many hardware security modules and secure enclave technologies support secp256r1 natively. This enables secure key storage and signing operations, enhancing the overall security posture of Solana-based applications.
Decentralized Identity and Authentication

Secp256r1 is widely used in decentralized identity (DID) frameworks and authentication protocols. Its integration with Solana enables robust, standards-compliant identity solutions that can interoperate with external systems.

For Developers: Getting Started

If you're a developer interested in implementing secp256r1 signatures in your Solana applications, you can start by exploring the solana-secp256r1-program crate, which provides the necessary functionality for signature verification.

The library is available through standard Rust package managers and is designed to be straightforward to integrate with existing Solana programs.

use agave::precompiles::secp256r1::verify_secp256r1_signature;

let message: &[u8] = b"hello solana";
let signature: &[u8] = /* 64-byte DER-encoded signature */;
let public_key: &[u8] = /* 33-byte compressed or 65-byte uncompressed public key */;

let is_valid = verify_secp256r1_signature(message, signature, public_key);

if is_valid {
    // Proceed with authenticated action
} else {
    // Reject or error
}

Conclusion

The integration of secp256r1 into Solana represents an important step in blockchain evolution-making advanced cryptographic security more accessible through familiar interfaces.

By embracing standards that bridge the traditional web with blockchain technology, Solana is reducing the barriers to entry for new users while providing enhanced security and flexibility for everyone. Whether you're a developer building the next generation of decentralized applications or simply someone who wants a more secure and convenient way to interact with blockchain systems, this update offers something valuable.

The true impact of this change will be measured not in technical specifications but in user experience. As more applications adopt these new capabilities, we may finally see blockchain technology fulfill its promise of being not just secure and decentralized, but also intuitive and accessible to everyone.

References

Exploring Anchor v0.31.0: Key Features and Enhancements

Mitch — Tue, 18 Mar 2025 10:04:18 +0000

INTRODUCTION

Anchor has long been a cornerstone in Solana development, for writing, testing, deploying, and interacting with Solana programs.The release of version 0.31.0 marks a significant milestone(this is the last major update before v1 is actually released) 0.31.0 introduces more enhancements to development workflows, compatibility improvements, and updates to its core features.

This article explores the technical advancements in Anchor v0.31.0, including new features like dynamic discriminator support and improved IDL generation workflows, alongside bug fixes that streamline program interaction. Let’s dive into everything you need to know about this update with detailed explanations and code examples.

Custom Discriminators

Anchor automatically generated an 8-byte discriminator for each account, limiting flexibility when integrating with other programs. With this update, you can now define your own discriminator values, including using zero-length discriminators where needed.

Why is this useful?

Allows better interoperability with non-Anchor programs.
Provides more control over account structure.
Reduces overhead when specific discriminators are unnecessary.

Example on setting a custom discriminator

#[account(discriminator = 1)]
pub struct MyAccount{
    //define account fields
}

This ensures that MyAccount is identified using the discriminator 1, rather than the default auto-generated one.

LazyAccount: Optimized Deserialization

This experimental feature introduces a new account wrapper that defers deserialization until the account data is accessed. It improves performance with large accounts and optimizes execution time in complex transactions.

Why is this useful?

Improves performance when working with large accounts.
Reduces unnecessary deserialization overhead.
Optimizes execution time in complex transactions.

Example

#[derive(Accounts)]
pub struct MyInstruction<'info> {
    #[account(lazy)]
    pub my_account: LazyAccount<'info, MyAccount>,
}

With this implementation, my_account will only be deserialized if its data is accessed, saving computational resources.

To enable this feature, you need to activate it in Cargo.toml:

anchor-lang = { version = "0.31.0", features = ["lazy-account"] }

Conditional Compilation for Instructions

Anchor now supports Rust’s cfg attributes for conditionally compiling instruction functions. This allows feature-gated logic within programs.

#[cfg(feature = "experimental")]
pub fn my_instruction(ctx: Context<MyInstruction>) -> Result<()> {
    // Implementation only available when "experimental" feature is enabled
    Ok(())
}

Improved Account Resolution Errors

Previously, Anchor returned vague error messages when accounts were missing during validation. Now, it provides more detailed error messages,

before

Account validation failed

now

Missing: token_account (AssociatedToken)

Mock RPC for More Reliable Testing

Anchor’s RPC client previously depended on live network conditions, causing inconsistent test results.You can now use new_mock to simulate specific states in tests. This help dependency on live Solana clusters and ensuring deterministic test outcomes.

before

let client = RpcClient::new(cluster_url); // Unpredictable network responses

after

let client = RpcClient::new_mock("airdrop=100"); // Controlled environment

New `Builder` Struct for Programmatic IDL Creation

You can now dynamically generate IDLs using the IdlBuilder struct instead of manually defining JSON files.

before

{
  "name": "my_program",
  "instructions": [
    {
      "name": "initialize",
      "accounts": ["param1", "param2"]
    }
  ]
}

now

let idl = IdlBuilder::new()
    .name("MyProgram")
    .instruction("initialize", vec!["param1", "param2"])
    .build();

In addition to introducing powerful new features, Anchor v0.31.0 also brings a host of improvements and optimizations aimed at enhancing developer workflows and ensuring compatibility with evolving Solana toolchains. Let’s explore these updates in detail.

Improvements in Anchor 0.31.0

🚀 Performance Enhancements

Reduced Stack Memory Overhead: Previously, initializing multiple accounts with init consumed significant stack space, potentially causing stack overflows in complex programs. This update moves init processing into a separate stack frame, reducing stack usage without requiring syntax changes.

🛠️ Developer Workflow Enhancements

Automatic Legacy IDL Conversion : Legacy IDLs (pre-Anchor v0.30) are now automatically converted to the new format during builds, eliminating the need for manual anchor idl convert commands.
Note: The anchor idl fetch command does not support auto-conversion..
Shell Completions for Anchor CLI : Developers using the can now enable shell autocompletion for faster command execution.

🧪 CLI & Testing Improvements

Passing Cargo Args to IDL Build

You can now pass Cargo feature flags when building the IDL.This ensures that the IDL is built with specific features enabled
```
anchor build -- --features my-feature
```
--no-idl Flag for Tests

If program logic remains unchanged but tests need to run frequently, this flag skips rebuilding the IDL, saving time:
```
anchor test --no-idl
```
Mollusk Test Template

Initialize an Anchor workspace with pre-configured tests using this new template:
```
anchor init my-program --test-template mollusk
```
This template provides pre-configured tests, making it easier to start new projects with testing in mind.
Enhanced anchor clean command

Previously, anchor clean only removed build artifacts.
anchor clean it now also removes the .anchor directory, behaving like cargo clean but keeping program keypairs intact.

Compatibility Updates

⚠️ Deprecation Warning (Solana v1.18.19)

Solana binaries are being renamed to Agave, and solana-install has been deprecated as of Solana v1.18.19 If you're using an older version of Anchor, this can cause parsing failures when running Solana-related commands.

If you attempt to use solana-install, you will now see this warning:
```
solana-install is deprecated and will be discontinued when v1.18 is no longer supported. 
Please switch to Agave: https://github.com/anza-xyz/agave/wiki/Agave-Transition
```
To avoid issues, Anchor 0.31.0 automatically installs and switches to agave-install when you specify solana_version greater than 1.18.19 in Anchor.toml.

How to Ensure Agave is Used

Modify your Anchor.toml like this:

[toolchain]
solana_version = "2.1.0"

Alternatively, you can manually install Agave with:

sh -c "$(curl -sSfL https://release.anza.xyz/v2.1.0/install)"

‼️ Solana-Program Warning

Adding solana-program as a dependency might cause conflicts between Solana v1 and v2 crates. If solana-program is present in your dependencies, you’ll now see this warning:


WARNING: Adding `solana-program` as a separate dependency might cause conflicts.
To solve, remove the `solana-program` dependency and use the exported crate from `anchor-lang`.
`use solana_program` becomes `use anchor_lang::solana_program`.

⚙️ How to Fix This Issue
Simply remove solana-program from your Cargo.toml:

[dependencies]
# Remove this:
# solana-program = "2.0.0"

Use this instead:
anchor-lang = "0.31.0"
Then, update your imports:

// OLD
use solana_program::pubkey::Pubkey;

// NEW (correct way)
use anchor_lang::solana_program::pubkey::Pubkey;

How to upgrade

Install the latest version of avm:

cargo install --git https://github.com/coral-xyz/anchor avm --force

This will allow installing Anchor CLI without having to compile from source.

Update anchor-cli: avm install 0.31.0
Update Anchor crate(s) to 0.31.0.
Update TS package(s) to 0.31.0.

Install from binary

avm install now downloads binaries from GitHub by default.

The following build targets are supported:

aarch64-apple-darwin
x86_64-unknown-linux-gnu
x86_64-apple-darwin
x86_64-pc-windows-msvc

You can add the --from-source flag to the install command if that's preferred (or required due to unsupported platform)

Impact on Development Workflow

Building on the improvements introduced in Anchor 0.31.0, this release significantly enhances the development workflow by streamlining debugging, testing, and configuration processes. The clearer error messages and more reliable testing tools reduce the time spent diagnosing issues, allowing teams to focus on feature development.

Performance optimizations, such as lazy deserialization for accounts, improve the efficiency of complex programs. This not only reduces computational overhead during development but also enhances deployment performance. For instance, lazy deserialization is particularly beneficial in read-heavy applications where accounts are frequently accessed but rarely modified.

The inclusion of features like shell autocompletion for the Anchor CLI and expanded support for conditional compilation makes the framework more intuitive and adaptable to specific project needs. These updates collectively enhance productivity and reduce the learning curve for both new and experienced developers. For new developers, the simplified program initialization and configuration process, combined with improved documentation and tools, lower the barrier to entry by providing a more straightforward path to building Solana programs.

Compatibility and Migration

Anchor 0.31.0 is designed with backward compatibility in mind, ensuring a seamless transition for existing projects while future proofing applications against upcoming ecosystem changes. The automatic conversion of legacy IDLs simplifies migration efforts, allowing you to upgrade without extensive manual intervention. This ensures that older projects can leverage the latest features without requiring significant refactoring.

The framework also adapts seamlessly to Solana's evolving toolchain by supporting Agave binaries for Solana v1.18+ users, eliminating potential parsing failures caused by deprecated tools like solana-install Configuring projects to use the latest Solana versions is straightforward, ensuring compatibility with future updates. The migration process is well-documented, with clear instructions for upgrading both Rust-based programs and TypeScript SDKs, minimizing downtime and ensuring project stability throughout the transition.

✅ Conclusion

In conclusion Anchor 0.31.0 is really more than just an update this release makes building on Solana faster, easier, and even more efficient. The reduced learning curve, enhanced CLI, and more reliable testing workflows mean both newcomers and experienced builders can work smarter, not harder. With v1 on the horizon, Anchor’s trajectory suggests continued focus on performance, flexibility, and developer experience. Expect future releases to build on these foundations, potentially expanding cross program integration capabilities and refining testing frameworks to meet the evolving needs of the ecosystem.

For a deeper dive you can check out the
Anchor 0.31.0 release notes and the full CHANGELOG

DEV Community: Mitch

Gasless Transactions on Solana

How Solana Transactions Normally Work

Example: David Sends SOL to Samuel.

Why SOL Is Always Required for Gas

Kora's Core Innovation

Kora Transaction Flow: From Friction to Seamless

Kora's Technical Architecture

The Four Pillars of Kora's architecture

Signer Options

1. Solana Private Key (Self-Managed)

2. Turnkey Integration (Enterprise)

3. Privy Integration (Web3 Apps)

Authentication: Securing Your RPC Endpoint

Method 1: API Key Authentication

Method 2: HMAC Authentication

Configuration Management

Key Configuration Sections

Getting Started with Kora

Prerequisites

Step 1: Install the Kora RPC Server

Step 2: Clone the Demo Project

Step 3: Install Client Dependencies

Step 4: Initialize the Local Environment

Step 5: Configure kora.toml

Step 6: Start Services (Multi-Terminal Setup)

Terminal 1: Start Local Test Validator

Terminal 2: Initialize Environment

Terminal 3: Start Kora RPC Server

Terminal 4: Run Client Demo

Production Deployment and Infrastructure Management

Deployment Options: Self-Host vs. Cloud

Scaling Considerations

Security Best Practices

Authentication Security

Signer Key Security

Real-World Impact: Emerging Markets

Building the Future

Ready to Start Building?

Friction to Flow

The $3 That Broke Crypto UX (And How Kora Fixed It)

Kora's Solution: Pay Fees with Any Token

How It Works: Before and After

Use Cases

Integrating Kora

What is a Kora Node?

Who Are Node Operators?

Economic Considerations

Security Imperatives

Operational Considerations

Running Kora Locally

Prerequisites

Quick Setup

Building the Future

Solana's Bridge Between Web2 and Web3

What's the Big Deal About Secp256r1 Signatures?

Digital Signatures 101: The Basics

What Makes Secp256r1 Special?

📊 secp256r1 vs ed25519 vs secp256k1

What this could potentionally mean for YOU

The Technical Corner: For Those Who Want More Detail

Mathematical Foundations of secp256r1

Key Generation

Signing Process

Verification Process

Implementation Timeline and Current Status

Practical Applications: What Can Be Built With This?

Cross-Chain Transactions

Regulatory Compliance

Hardware Security Modules (HSMs) and Secure Enclaves

Decentralized Identity and Authentication

For Developers: Getting Started

Conclusion

References

Exploring Anchor v0.31.0: Key Features and Enhancements

INTRODUCTION

Custom Discriminators

LazyAccount: Optimized Deserialization

Conditional Compilation for Instructions

Improved Account Resolution Errors

What's the Big Deal About `Secp256r1` Signatures?

What Makes `Secp256r1` Special?

Mathematical Foundations of `secp256r1`

New `Builder` Struct for Programmatic IDL Creation