Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Architecture decision records

This section captures the durable architectural decisions behind Pina’s public model, safety posture, and verification strategy.

ADR format and naming

  • Files live under docs/src/adrs/.
  • ADRs use the naming pattern NNNN-short-slug.md.
  • The starter template lives at docs/src/adrs/0000-template.md.
  • Architecture-impacting pull requests should link the ADR they follow or update.

ADR index

ADRStatusDecision
ADR 0001AcceptedKeep discriminator bytes as the first field inside typed layouts.
ADR 0002AcceptedKeep zero-copy for fixed-size Pod layouts, but only behind explicit validation.
ADR 0003AcceptedKeep runtime borrow guards alive for the full typed loader lifetime.
ADR 0004AcceptedPreserve no_std / no-allocator constraints for on-chain code paths.
ADR 0005AcceptedKeep SPL token support optional and feature-gated.
ADR 0006AcceptedTreat CI as layered verification, not a single all-purpose test lane.
ADR 0007ProposedMake migrations a generated, on-demand, versioned ABI compatibility boundary.
ADR 0008ProposedReserve a migration instruction, add client migrate-first flow, and support adopting migrations on already-launched programs.
ADR 0009AcceptedGive pina_abi its own release line, pin a committed abiVersion to it, reset the document to stored facts, and publish generated JSON Schemas.
ADR 0010AcceptedBound the entrypoint account array per program and keep pinocchio as a library; ADR 0011 proposes revisiting its rejection of a dispatcher.
ADR 0011ProposedDispatch on the SIMD-0321 instruction-data pointer before reading accounts, parse only the routed instruction’s accounts, and re-verify stored-bump PDAs with sha256.
ADR 0012AcceptedJudge instruction account slots on wire facts only; defaultValue and pda client hints never block a version.

How to use this section

Use these ADRs when you need to answer questions like:

  • why Pina uses discriminator-first layouts instead of external headers
  • when zero-copy is allowed, and where the safety boundaries are
  • why typed account loaders must be guard-backed instead of returning bare references
  • why no_std and allocator constraints are treated as architecture, not implementation detail
  • why token helpers are optional instead of always-on
  • why Miri, compile-fail tests, feature matrices, and compute-unit checks all exist at once
  • why the ABI document’s abiVersion is a committed value pinned to pina_abi’s own release line instead of counting format revisions
  • why a changed PDA or known-address hint on an instruction account never blocks a published version