pina

Pina is a Solana program framework built on pinocchio: programs deploy with the smallest binaries of any Solana framework, spend compute like hand-written code, and evolve through the only managed ABI migrations in the ecosystem.

Why Pina? · Comparison · Getting Started · Docs · Examples · Contributing

⚠️ Pina is currently unaudited and still hardening. See SECURITY.md for the current readiness statement, supported versions, and private vulnerability reporting instructions.

• Smallest binaries, lowest framework overhead: built on pinocchio instead of solana-program, so the framework's dispatch and validation cost a few bytes and a few compute units, not thousands of CU per instruction.
• no_std and allocation-free: every on-chain crate compiles to the bpfel-unknown-none SBF target with no heap and no allocator.
• Framework-managed ABI migrations: version envelopes, generated transitions, and a publication ledger evolve account and instruction schemas without breaking deployed programs — the only Solana framework that ships this.
• Validated zero-copy deserialization: PinaPod validates account data before Pina returns an in-place view, with no heap allocation.
• Discriminator-first layouts: every account, instruction, and event type carries a typed discriminator as its first field, one byte by default.
• Declarative validation: chain assertions on AccountView references, or compile #[pina(validate(...))] rules into allocation-free checks.
• Proc-macro sugar: #[account], #[instruction], #[event], #[error], #[discriminator], and #[derive(Accounts)] eliminate boilerplate.
• CPI helpers: PDA account creation, lamport transfers, and token operations as documented instruction structs.

Macros stay minimal, the IDL is inferred from the validation code you already write (payer.assert_signer()? becomes a signer constraint in the generated IDL), and one language runs end to end: on-chain Rust, and generated Rust, TypeScript, or Dart clients. The project goals describe the philosophy in full.

✅ first-class · 🟡 partial · ❌ not available.

Anchor v1 is the current stable line and Anchor v2 its pre-release rewrite; both share one CLI. Quasar publishes no versioned crates, so its pinned revision is the version; the pin is the 0.2.0-release branch head. The Pina version follows this repository and refreshes on every release. Update the Anchor and Quasar cells here when bumping the fixtures under benchmarks/framework-comparison/.

The same hello-world and counter programs written in each framework, built with cargo build-sbf --lto under one release profile, and executed in a Mollusk VM. Pinocchio (hand-written) is the compute-unit floor a framework has to justify; Pina's counter is also smaller than it. Regenerate with devenv shell -- benchmark:frameworks; the full methodology and caveats live in the framework comparison.

The unchecked hello is a benchmark opt-in that omits program-ID, signer, and exact payload-length checks. The SIMD-0312 counter enables create-account-allow-prefund, requiring that runtime feature and exchanging 11 initialization CU for 1,216 fewer bytes. Default builds retain the original checks and allocation sequence. See the comparison methodology for validation and account-layout differences.

cargo add pina

To enable SPL token support:

cargo add pina --features token

Install the prebuilt CLI from npm on macOS, Linux, Windows, or FreeBSD:

npm install --global @pina-rs/cli
pina --help

The Rust-native installation remains available with cargo install pina_cli. Agent tooling can install the bundled project skill separately:

npm install --global @pina-rs/skill
pina-skill --install

Scaffold a program and run it through its first build:

pina init my_program
cd my_program
pina build
cargo test

• Getting started — toolchain setup and project layout.
• Your first program — accounts, instructions, and dispatch, end to end.
• Migrating from Anchor — a side-by-side mapping of Anchor concepts.
• Crate features — compact, validation, token, account-resize, and the logging toggles.

The book is the documentation home; API docs are on docs.rs. Frequently used pages:

• Framework comparison — how the tables above are measured.
• How ABI migrations flow — version envelopes, transitions, and the publication ledger.
• Core concepts — accounts, instructions, discriminators, and validation chains.
• Security model and the security guide — vulnerable and secure patterns for all 11 common Solana attack categories.
• Pina CLI reference — every command, including pina lint, pina profile, pina dev, and pina deploy --rehearse.
• Codama workflow — IDL extraction and client generation for Rust, JS/TS, and Dart.
• sbpf-linker evaluation — the experimental upstream toolchain that builds smaller binaries without cargo build-sbf, with the measured trade-offs.

Twenty-eight examples live in examples/; the annotated list is in the docs. The Anchor parity ports (declare-id, declare-program, duplicate-mutable-account checks, sysvar checks, custom errors, …) keep behaviour comparable while you migrate.

Pina validates account identity, signer status, writability, ownership, and data shape before any cast, mutation, or CPI, and its security lints catch common Solana mistakes at compile time:

pina lint

See SECURITY.md for the readiness statement and private vulnerability reporting, the security model for the guarantees Pina does and does not make, and the security guide for worked vulnerable/secure pairs across all 11 common Solana attack categories.

Contributions are welcome! Please open an issue or pull request on GitHub. Read the development workflow first — this repository reproduces every CI job locally before pushing.

Licensed under the Apache License, Version 2.0.