What did you build?

Quasar is a framework for writing programs that run on Solana. Think of it as the toolbox + rulebook that makes writing Solana programs less painful.

Solana already has a popular framework called Anchor. Quasar is a direct competitor, but with one obsession: spending as few compute units as possible.

The project's anatomy

The repo is a Cargo workspace — one repo, many crates, all compiled together. Here's what each folder is responsible for:

Check your understanding

Who owns what?

Click any component below to see what it's responsible for and how to steer AI when working with it.

How the crates talk at build time

When you run quasar build, the crates collaborate in a chain. Here's what they say to each other:

Where would you look?

The escrow example — your guiding story

The most complete example in the repo is examples/escrow/. It implements a classic token escrow: Alice locks Token A, Bob sends Token B, they swap atomically. Three instructions: make, take, refund.

The make instruction — traced end to end

Press play to walk through every step from client call to final state:

The make instruction — decoded

Here's the actual lib.rs for the escrow, translated line by line:

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

  #[instruction(discriminator = 0)]
  pub fn make(
    ctx: Ctx<Make>,
    deposit: u64,
    receive: u64,
  ) -> Result<(), ProgramError> {
    ctx.accounts.make_escrow(
      receive, &ctx.bumps
    )?;
    ctx.accounts.emit_event(
      deposit, receive
    )?;
    ctx.accounts.deposit_tokens(deposit)
  }
}

What lives on-chain — the Escrow account

After make runs, an Escrow account is written to the blockchain. This is its exact shape:

#[account(discriminator = 1)]
pub struct Escrow {
  pub maker:      Address,  // 32 bytes
  pub mint_a:     Address,  // 32 bytes
  pub mint_b:     Address,  // 32 bytes
  pub maker_ta_b: Address,  // 32 bytes
  pub receive:    u64,      //  8 bytes
  pub bump:       u8,       //  1 byte
}

Trace the take instruction

Macros — code that writes code

A proc-macro in Rust is like a stamp. You press it on your code and it produces a much larger imprint. Quasar ships five core stamps, each in derive/src/:

The Accounts derive — your program's front door

Every instruction has an accounts struct. The #[derive(Accounts)] macro reads your field annotations and generates the entire parse_accounts() function:

#[derive(Accounts)]
pub struct Make<'info> {
  #[account(mut, signer)]
  maker: UncheckedAccount<'info>,

  #[account(
    init,
    seeds = [b"escrow", maker],
    payer = maker,
    space = Escrow::SPACE,
  )]
  escrow: Account<'info, Escrow>,

  #[account(address = system_program::ID)]
  system_program: UncheckedAccount<'info>,
}

PDAs — deterministic addresses you control

A PDA is how Quasar programs create accounts they control. Like giving each escrow deal its own pigeonhole in a post office — always at the same slot, always only accessible to the program.

Know your macros

Zero-copy — the core trick

This is Quasar's central design decision. Let's make it concrete.

How safety is maintained despite unsafe Rust

Quasar uses unsafe for its zero-copy pointer casts. Three guarantees make this sound:

CPI — how Quasar programs call other programs

CPI is how Quasar programs talk to external programs (Token, System, etc.). Quasar's CPI builder is const-generic — the number of accounts is baked in at compile time, so it allocates on the stack, not the heap.

// Stack-allocated CPI — no heap needed
let cpi = TransferCpi::new(
  system_program,
  [from_account, to_account],
);
cpi.invoke_signed(&[
  &[b"escrow", maker_key, &[bump]],
])?;

The IDL — your program's public contract

The IDL is generated by quasar idl <path>. It parses your Rust source and produces three outputs:

Spot the design principle

Every quasar command, explained

Quasar.toml — your project's control panel

Every Quasar project has a Quasar.toml that tells the CLI how to behave. It's small but important:

[project]
name = "my-program"

[toolchain]
type = "solana"
# or "upstream" for nightly BPF

[testing]
framework = "mollusk"
# or: "none", "quasarsvm-rust",
# "quasarsvm-web3js", "quasarsvm-kit"

The profiler — your CU budget dashboard

The profiler in profile/ statically walks the compiled binary's call graph using DWARF debug info. No transaction needed — it reads the binary like an X-ray.

How tests work in Quasar

Tests use Mollusk — a fast in-process SVM. The test sets up fake accounts, builds an instruction using the generated IDL client, and checks the resulting account state:

fn setup() -> Mollusk {
  Mollusk::new(
    &crate::ID,
    "../../target/deploy/quasar_escrow"
  )
}

let result = mollusk.process_instruction(
  &instruction,
  &[(maker, maker_account), ...],
);
assert!(result.program_result.is_ok());
// Then inspect result.resulting_accounts

Put it all together