Unidentified program

No Anchor or Pinocchio markers in the binary, and a stripped or unusual symbol table.

Framework can't be read off the ELF — either heavily stripped, a niche framework, or a non-Rust toolchain.

Unknown toolchain.

What it is

The binary didn't carry a framework signature we recognize — no Anchor error table, no Pinocchio C-ABI tell, and no readable symbols to work from.

When to pick it

Not applicable — this is a detection gap, not a developer choice.

How it looks on-chain

Nothing to fingerprint. Could be a stripped build, a niche or new framework, or a non-Rust toolchain.

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.