This program's bytecode is byte-identical to other deploys on record — the same program under a fresh id. It was closed within 18m. The signature of a throwaway bot: deploy a disposable id, run it hot, then close it to reclaim the rent — and repeat.
What's a throwaway bot?
A disposable on-chain program a trader deploys to run one strategy — almost always sniping new Pump.fun token launches — then closes minutes later to reclaim its rent, redeploying under a fresh id for the next run.
Why a program at all?
Sniping means "buy the instant the pool exists, atomically, or abort" — you can't do that reliably from a wallet. A tiny custom program bundles the whole attempt (and often multi-venue routing) into a single instruction that either lands complete or reverts.
Why thousands of failed transactions?
That's the race. The bot fires on every launch; most attempts lose the block or the token rugs, so they revert. The failures are the strategy — spray for the few that land.
Why redeploy and close?
The ~0.2 SOL of rent is refundable on close, and a fresh program id sidesteps any blocklist or reputation built against a known address. Cheaper and stealthier to burn identities than to keep one — so one operator can wear dozens of "new program" identities in a day.
How On Record catches it
Exact-bytecode dedup (same sha256 = same bot) collapses the redeploys into one cluster; lifecycle tracking sees the deploy → close; the failed-tx count confirms the intent. No explorer distinguishes "new protocol" from "same bot, 30th identity today" — that's a novelty-definition problem, which is exactly what this radar solves.
Lineagei
Frameworki
What's Anchor?
Batteries-included Rust framework. Ships account-validation codegen, 8-byte instruction discriminators, and an on-chain IDL — the program describes itself.
Bigger binary and higher rent in exchange for safety rails, introspection, and dev speed. The choice of a team optimizing for correctness over on-chain footprint.
Originally Coral (Armani Ferrante); now community-maintained.
What it is
The de facto standard. Rust macros (#[program], #[derive(Accounts)]) eliminate boilerplate: it auto-generates 8-byte account and instruction discriminators — SHA256("account:<Name>")[..8] and SHA256("global:<ix>")[..8] — handles Borsh (de)serialization, enforces account constraints declaratively (mut, has_one, seeds, init), and emits a JSON IDL that client libraries consume directly. The cost: Borsh copies data on every deserialize (not zero-copy), and the macro machinery adds binary bloat and compute overhead — irrelevant for ~99% of programs.
When to pick it
Building a new protocol, moving fast, or wanting maximum ecosystem compatibility. It's the beginner default and stays the right call for most production programs.
How it looks on-chain
The most recognizable framework. Every account it owns begins with an 8-byte discriminator, and the IDL is often published on-chain at a PDA derived from the program id. Both are strong, reliable fingerprints — this is the only framework we can label with confidence.
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.
Anchor docsFootprinti
Recovered architecturei
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 — Pinocchio, native, Steel — 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.