Solana: Pinocchio vs Quasar program frameworks

Documentation Index

Fetch the complete documentation index at: https://docs.chainstack.com/llms.txt

Use this file to discover all available pages before exploring further.

• Pinocchio and Quasar are both zero-copy, high-efficiency Solana program frameworks, but they optimize for different things.
• Pinocchio is low-level and audited (p-token is built on it): maximum control, but you write the owner, signer, and discriminator checks yourself.
• Quasar is a newer, beta, unaudited framework with Anchor-like ergonomics that keeps Pinocchio-level efficiency and is zero-copy by default.
• Rule of thumb: reach for Quasar to write an efficient program quickly; reach for Pinocchio for byte-level control or an audited, battle-tested base.

​

The framework spectrum

• Native — a raw entry point and manual pointer work. Maximum control, no safety nets.
• Pinocchio — a thin, zero-copy library: safe account and instruction views, entry-point macros, and CPI helpers, but no validation or routing. You write those.
• Quasar — an Anchor-like macro layer (account validation, discriminators, PDA seeds, context structs) that compiles down to Pinocchio-tier efficiency and is zero-copy by design.
• Anchor — the full-featured, most battle-tested framework: borsh serialization, 8-byte discriminators, IDL and client generation. The highest developer experience and the highest compute cost.

​

Pinocchio

• entrypoint! — parses the whole input (all accounts and instruction data) before calling your function. Best for programs with many instructions, where that one-time parse is amortized.
• lazy_program_entrypoint! — hands you a context and parses nothing until you ask for it, so you pay only for the accounts and data you touch. Best for programs with one or a few instructions; it dropped the memo program’s compute by roughly 80–87%. Note that, unlike the standard entry point, it does not detect duplicate accounts for you.

// pinocchio = "0.11"
use pinocchio::error::ProgramError;
use pinocchio::{entrypoint, AccountView, Address, ProgramResult};

entrypoint!(process_instruction);

pub fn process_instruction(
    program_id: &Address,
    accounts: &mut [AccountView],
    instruction_data: &[u8],
) -> ProgramResult {
    let [counter, authority, _rest @ ..] = accounts else {
        return Err(ProgramError::NotEnoughAccountKeys);
    };

    // You write these checks — the framework does not.
    if !authority.is_signer() {
        return Err(ProgramError::MissingRequiredSignature);
    }
    if counter.owner() != program_id {
        return Err(ProgramError::IncorrectProgramId);
    }

    match instruction_data.first() {
        Some(&0) => Ok(()), // increment the counter in place
        _ => Err(ProgramError::InvalidInstructionData),
    }
}

​

Quasar

#![no_std]
// Install the CLI with `cargo install --path cli`, then scaffold with `quasar init`.
use quasar_lang::prelude::*;

declare_id!("YourProgramID11111111111111111111111111111111");

// State account — 1-byte discriminator, PDA seeds, zero-copy.
#[account(discriminator = 1, set_inner)]
#[seeds(b"counter", authority: Address)]
pub struct Counter {
    pub authority: Address,
    pub count: u64,
}

// Validated accounts — constraints replace the hand-written checks.
#[derive(Accounts)]
pub struct Increment {
    #[account(mut, address = Counter::seeds(authority.address()))]
    pub counter: Account<Counter>,
    pub authority: Signer,
}

#[program]
mod my_counter {
    use super::*;

    #[instruction(discriminator = 0)]
    pub fn increment(ctx: Ctx<Increment>) -> Result<(), ProgramError> {
        ctx.accounts.counter.count += 1;
        Ok(())
    }
}

​

Efficiency in context

​

Which should you use?

• Choose Quasar when you want to ship an efficient program fast and let the framework prevent common mistakes — and you can accept beta, unaudited software.
• Choose Pinocchio when you need full control for byte-level optimization, or you want an audited, battle-tested foundation for a security-critical program.

​

Caveats

• Quasar is beta and unaudited — its README states it “has not been audited. APIs may change. Use at your own risk.” It ships through its own CLI (quasar init) rather than versioned crates.io releases (the published 0.0.0 crate is a placeholder), so pin to a specific commit and expect breaking changes. Do not ship it to production without your own audit. Its 1-byte discriminators are also incompatible with Anchor’s 8-byte scheme, which matters if you parse or migrate across both.
• Pinocchio has no safety nets — a single missed owner, signer, or discriminator check is a vulnerability. Pin a version, since the API has shifted across releases.
• An Anchor v2 built on a Pinocchio entry point is in development (not released as of this writing) and may reshape this comparison once it ships.

​

Additional resources

• Anchor development — the full-featured framework this page contrasts against.
• p-token batch instruction — a production program built on Pinocchio.
• anza-xyz/pinocchio — source, docs, and examples.
• blueshift-gg/quasar — source, and quasar-lang.com for the docs.