arena-lock-v2

Built directly on the solana-program SDK with no framework layer. Bespoke account handling and dispatch.

Footprint sits between Anchor and Pinocchio. The choice of a developer who wants control without Anchor's overhead and doesn't need its guardrails.

Raw Rust against the official solana-program crate.

What it is

No framework. You handle account deserialization, discriminators, security checks, CPI construction, and IDL generation yourself. Maximum control, maximum verbosity, and no abstraction overhead.

When to pick it

A small utility program, tooling, or when you have a specific reason to avoid all dependencies. Few new production protocols start here from scratch.

How it looks on-chain

No enforced layout — nothing to fingerprint. Indistinguishable from other minimal frameworks (Steel, hand-rolled setups) by account data alone.

Others in the wild: Steel (Ore team — near-native performance on solana-program), Seahorse (Python → Anchor), and Poseidon & Quasar (TypeScript → Rust). Transpilers inherit their lowering target's fingerprint: a Quasar or Poseidon program that compiles down to Anchor will look like Anchor on-chain — discriminators and all.

The upgrade authority is the account allowed to replace a program's code after it's deployed.

If it's set (mutable), that key can push new bytecode at any time — including malicious code, the classic "rug" vector. If it's null (immutable / frozen), the code can never change; what 's on-chain is final. A Squads multisig sits in between — upgrades are possible but need M-of-N signers, not one hot wallet. So mutable + single hot-wallet = highest risk; immutable or multisig = stronger guarantees.

A verified build proves the program running on-chain was compiled from the public source you can read — nothing hidden.

Someone re-compiles the source in a deterministic (Docker) environment and checks the resulting bytecode is byte-for-byte identical to what's deployed; tools like solana-verify do this and record it with a verification service. "Not verified" isn't a red flag by itself — most programs simply never submit one. It just means you're trusting the deployed bytecode as-is, with no source cross-check.

An IDL — Interface Description Language — is a JSON spec that describes how to talk to a program: its instructions, the accounts each one needs, argument and account types, events, and errors.

Anchor auto-generates it at build time. A program can publish it on-chain at a PDA derived from its id, so any client or explorer can decode the program's transactions without its source code.

Why it's often missing

Publishing is opt-in — a courtesy, not a requirement. Many programs never do, and non-Anchor frameworks (Pinocchio, native, Steel) don't produce one at all; their interface lives in an off-chain Shank/Codama artifact, or nowhere public. Absence means you can't auto-decode it — not that anything is wrong.