Unidentified program
This program's bytecode is byte-identical to other deploys on record — the same program under a fresh id. It was closed within 27m. 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 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
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 — 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.
Tractioni
The recordi
| Event | When | Detail | Receipt |
|---|---|---|---|
| DEPLOY | 4h ago | slot 432,700,462 | poll…0462 |