This bytecode is byte-identical to 4 other deploys on record — same code, fresh id. That can be a bot rotating identities, or a factory/launchpad deploying instances of one program, or a developer redeploying. We don't assume which — it's simply not novel code, so it's kept off the novelty radar.
Lineagei
Frameworki
What's Native?
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.
Native docsFootprinti
Reachi
Controli
What's upgrade authority?
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.
What's a verified build?
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.
Convictioni
No IDL publishedi
This program hasn't published an IDL — the interface spec that would let its instructions be auto-decoded here.
That's normal, not a red flag. Publishing an IDL on-chain is opt-in — closer to a courtesy than a requirement. Anchor can write one to a PDA derived from the program id, but plenty of teams never do. And non-Anchor programs — like this Native one — have no built-in IDL at all; their interface lives in an off-chain Shank/Codama artifact, or nowhere public.
What's an IDL?
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.