pinocchio-development

Add pinocchio, pinocchio-system, pinocchio-token, and bytemuck to Cargo.toml, then define an entrypoint that routes instructions by a single-byte discriminator. Validate accounts manually, create PDAs with CreateAccount CPIs, and use bytemuck for zero-copy account data access.

Pinocchio reduces compute units by 88-95% and binary size by about 40% compared to Anchor, making it ideal for high-throughput programs like DEXs. Choose Anchor instead for rapid prototyping, complex account relationships, or when your team lacks low-level Rust experience.

Replace Anchor macros with manual validation: convert #[account] structs to bytemuck Pod types with explicit discriminators, turn constraint attributes into is_signer and is_writable checks, and swap CpiContext calls for pinocchio-system and pinocchio-token invoke helpers. Use Shank to generate the IDL.

Yes, pinocchio-token supports Token-2022 operations including metadata pointers and token metadata initialization, though support is under active development. For third-party programs without helper crates, build Instruction structs manually with AccountMeta and call invoke or invoke_signed.

Bytemuck structs must be padded to 8-byte alignment, and account data cannot be borrowed mutably while an immutable borrow exists. Drop the first borrow before borrowing again, and add explicit padding fields after any field smaller than 8 bytes.

Pinocchio is currently unaudited, so use it with caution in production despite being maintained by Anza. Mitigate risk by following the security checklist: verify account ownership, check all signers, validate PDAs, and use checked arithmetic to prevent overflow.