Phoenix: Eternal

Zero-dependency, no-std entrypoint. No codegen, no IDL — the developer hand-writes account parsing against the raw C ABI (sol_invoke_signed_c).

Tiny binary and low compute-unit cost, at the price of manual safety and no self-description. The choice for a hot path — routing, MEV, high-frequency — where every CU and lamport of rent is optimized.

Built by Anza (the Agave client team).

What it is

A drop-in replacement for the solana-program crate — not an Anchor-style framework. Its core innovation is zero-copy AccountInfo: instead of deserializing account data into an owned struct, it returns a pointer directly into the input buffer, eliminating a major class of memory copies and cutting CU usage on hot instructions. It has zero external dependencies and is no_std. It's completely unopinionated — no IDL, no account-validation helpers, no standard layout — so you bring Shank + Codama to generate IDLs and clients yourself. Still unaudited and not at full feature parity with solana-program.

When to pick it

Programs that process enormous volume where CU cost is the bottleneck — token programs, AMM hot paths, Ore-style mining. Not beginner-friendly.

How it looks on-chain

No enforced discriminator or account layout, and no on-chain IDL — so it can't be positively identified from account data. The tiny, dependency-free binary is the main tell, which is why we label it 'inferred'.

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.

A block of contact info a developer embeds directly in the program binary — the Neodyme convention — so whitehats know how to report a vulnerability.

It carries contacts, a disclosure policy, auditors, and a source link. It's self-declared, so treat it as a claim, not proof — but its presence signals a team that expects scrutiny and wants to be reachable.

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.