Quasar is aDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/blueshift-gg/quasar/llms.txt
Use this file to discover all available pages before exploring further.
no_std Solana program framework built around a single principle: account data should never be copied. Instead of deserializing bytes into heap-allocated Rust structs, Quasar pointer-casts account data directly from the SVM input buffer into #[repr(C)] companion types — eliminating both deserialization overhead and heap allocation entirely. You write familiar attribute macros like #[program], #[account], and #[derive(Accounts)], and the generated code compiles down to near-hand-written compute-unit efficiency. This page explains what Quasar is, why it was built, and where to find the resources you need to start using it.
Beta software. Quasar is under active development and has not been audited. APIs may change between releases. Use at your own risk in production environments.
Why Quasar?
Every Solana transaction is constrained by a hard compute-unit (CU) limit. Standard frameworks typically pay a serialization tax on every account access: bytes are read from the runtime input buffer, decoded through a schema (Borsh, for example), and written into a newly-allocated heap struct before your instruction logic ever runs. For programs where compute budget is the bottleneck, that cost is unavoidable overhead. Quasar’s answer is to skip deserialization entirely. The SVM runtime serializes each account into a contiguous region of the input buffer as aRuntimeAccount header followed immediately by the account’s raw data bytes. Because Quasar’s account types are #[repr(C)] with alignment 1, a pointer cast from the buffer address into the typed struct is both sound and free — no copy, no allocation, no schema traversal.
The ergonomics stay close to what Anchor developers already know: define account shapes with #[account], declare instruction accounts with #[derive(Accounts)], and group handlers under #[program]. The difference is entirely in the generated code — and in the CU bill at the end of execution.
The Zero-Copy Philosophy
#[repr(C)] Layouts and Pointer Casting
Account data structs annotated with #[account] in Quasar are compiled to #[repr(C)] companion types by the quasar-derive proc-macro crate. This guarantees a stable, predictable memory layout. When Quasar validates an account, it checks:
- The discriminator prefix matches the expected constant.
- The account is owned by the correct program.
- The data region is large enough for the declared struct.
borsh::BorshDeserialize, no bytemuck::from_bytes, no allocation — just a raw cast from a validated pointer.
No borsh, No Heap
Quasar is #[no_std] at its core. The alloc crate is only pulled in when the idl-build or debug Cargo features are active (i.e., never in an on-chain .so). Account types use alignment-1 Pod integers from the zeropod crate (zeropod::PodU64, zeropod::PodI32, etc.) so that multi-byte fields remain correct across pointer casts without requiring the buffer to carry non-trivial alignment.
Comparison to Anchor
| Anchor | Quasar | |
|---|---|---|
| Account access | Borsh deserialization into heap structs | Pointer cast from SVM input buffer |
| Discriminator | SHA-256 of "account:<TypeName>" | Developer-specified byte constant |
| Allocator | Global allocator always present | no_std; allocator only for non-SBF features |
| Ergonomics | #[account], #[derive(Accounts)], #[program] | Same macros, same patterns |
| CU overhead | Full deserialization per account | Near-hand-written (validation + cast only) |
| Safety model | Anchor constraints + Rust ownership | repr(C) + bounds check + discriminator + Kani proofs |
no_std guarantees and zero-allocation account access, Quasar is built for you.
Workspace Crates
Quasar is a Cargo workspace. Each crate has a focused responsibility:| Crate | Path | Purpose |
|---|---|---|
quasar-lang | lang/ | Account types, CPI builder, events, sysvars, error handling |
quasar-derive | derive/ | Proc macros: #[account], #[instruction], #[program], #[event], #[error_code], #[derive(Seeds)], emit_cpi!, #[derive(QuasarSerialize)] |
quasar-spl | spl/ | SPL Token and Token-2022 CPI helpers and zero-copy account types |
quasar-profile | profile/ | Static CU profiler with flamegraph output |
cli | cli/ | The quasar CLI — init, add, build, test, deploy, clean, config, idl, client, lint, profile, dump, keys, completions |
quasar-lang (the runtime) and quasar-derive (the macros). Add quasar-spl if your program interacts with SPL tokens.
Safety Model
Quasar’s use ofunsafe is deliberately narrow and mechanically verified:
- Alignment-1 guarantee: All Pod types and zero-copy companion structs are
#[repr(C)]with alignment 1. Compile-timeassert!statements verify this for every account type at build time. - Bounds checking: Account data length is validated during parsing before any pointer cast occurs. A cast only happens after the length check confirms the buffer is large enough.
- Discriminator validation: Developer-specified discriminators (not SHA-256-derived) are checked before account data is accessed. All-zero discriminators are banned at compile time to prevent uninitialized accounts from passing validation.
- Kani proofs: Every
unsafeblock is validated by Miri under Tree Borrows with symbolic alignment checking. Formal Kani model-checking harnesses run in CI forquasar-lang,quasar-spl, and the metadata crate.
Where to Go Next
Quickstart
Install the CLI, scaffold a project, and run your first Quasar program in under five minutes.
Core Concepts
Understand the SVM input buffer, zero-copy pointer casts, discriminators, and the compute-unit model.
Accounts
Explore the full account type system:
Account<T>, Signer, UncheckedAccount, Program<T>, and more.CLI Reference
Complete reference for every
quasar CLI command: init, add, build, test, deploy, clean, config, idl, client, lint, profile, dump, keys, and completions.