Prop AMM Teardown
APIChip in
The wallHuntVaultVerifierDocsAPI and MCP
Chip in on the wall

The wall and how targets are chosen

Where the list comes from, which programs stay on it, how they are ranked and what each target page shows.

Source of the list

The wall starts from Jupiter's public program-id-to-label list, the programs Jupiter routes swaps through, plus the programs visitors nominate. Each program is named only by its Jupiter label and its address, as public facts.

Which programs stay on the wall

A program is on the wall when all of these hold, read from Solana and from the OtterSec verification API:

  • the address is an executable program;
  • it is owned by the upgradeable loader (BPFLoaderUpgradeab1e11111111111111111111111);
  • it still has an upgrade authority;
  • OtterSec reports no verified build for it (is_verified is false);
  • no source repository is registered for it on OtterSec (no repo_url).

A program with a repository registered on OtterSec has public source even when its current build is not matched, so it is left off. Every program left off is listed in the wall's JSON with the reason. Tiles say "no verified build", which is what the OtterSec API reports; they make no claim about any team or protocol.

Prop AMMs and other closed programs

The wall opens on the prop AMMs: proprietary AMMs that quote from their own pricing logic instead of a public curve. The set is an editorial choice, made on 2026-11-02 from the labels present in Jupiter's live list that day:

  • HumidiFi 9H6tua7jkLhdm3w8BvgpTn5LZNU7g4ZynDmCiNN3q6Rp
  • SolFi SoLFiHG9TfgtdUXUjWAxi3LtvYuFyDLVhBWxdMZxyCe
  • SolFi V2 SV2EYYJyRz2YhfXwXnhNAevDEui5Q6yrfyo13WtupPF
  • TesseraV TessVdML9pBGgG9yGks7o4HewRaXVAMuoVj4x83GLQH
  • ZeroFi ZERor4xhbUycZ6gb9ntrhqscUcZmAbQDjEAtCf4hbZY
  • GoonFi V2 goonuddtQRrWqqn5nFyczVKaie28f3kDkHWkHtURSLE
  • Obric V2 obriQD1zbpyLz95G5n7nJe6a4DPjpFwa5XYPoNm113y
  • BisonFi BiSoNHVpsVZW2F7rx2eQ59yQwKxzU5NvBcmKshCSUypi
  • AlphaQ ALPHAQmeA7bjrVuccPsYPiCvsi428SNwte66Srvs4pHA
  • Aquifer AQU1FRd7papthgdrwPTTq5JacJh8YtwEXaBfKU3bTz45

Every other program that passes the filters above is listed under the second tab, "Other closed programs", with its own ranking. Both lists take chip-ins and submissions the same way. The set is revised by hand when Jupiter's list changes, and the date above moves with it.

Ranking

Each list is ranked by transactions over the last 24 hours. When a program's last 1,000 signatures reach back a full day, the figure is the exact count inside the window. When they do not, the cron reads up to 4,000 signatures, times the window by slots and block times, extrapolates to 24 hours and prints the figure with est.. RPC returns at most 1,000 signatures per call, which is why the busiest programs carry the mark.

The cron

A Vercel Cron runs every 15 minutes. Each run refreshes the program list when it is older than six hours (OtterSec statuses are re-read once a day, a slice at a time), samples the activity of the targets read longest ago, reads every escrow's USDC balance in one call, takes missing snapshots and adds to the instruction samples. The work is spread across runs to stay polite with the public RPC nodes.

Snapshots and upgrades

A snapshot records, for one deploy of the program:

  • the loader and the programdata account;
  • the upgrade authority;
  • the last deploy slot (programdata bytes 4 to 12);
  • the ELF, trimmed to its real size from the ELF header, its size and its sha256.

A snapshot is frozen once taken and keyed by its deploy slot. When the program is upgraded, the next cron run sees a new deploy slot and takes a new snapshot; the target page keeps the full history. A submission is always judged against the snapshot it targeted, even if the program was upgraded while it waited.

First look and instruction sample

The site computes, without AI, a first look at every snapshot straight from the ELF:

  • sections and their sizes, the sBPF version flags, the instruction count of .text;
  • syscalls, from the dynamic symbol table or, for static-syscall sBPF versions, from the murmur3 hash each call carries;
  • internal call targets, which give function boundaries as the call graph sees them, and the largest functions;
  • the printable strings of .rodata, which often name source files, errors and a security contact.

The cron also reads a few recent transactions per run and folds the instructions sent to the program into a sample: the first byte and the first 8 bytes of instruction data (the discriminators), how often each appears, and the account counts per discriminator.

The teardown kit

The judge machine computes the full kit from the ELF and the corpus: the sBPF disassembly, function count and sizes, syscalls, .rodata strings, the discriminator map over the whole corpus (first 1, 4 and 8 bytes), account counts per discriminator, writable and signer patterns, account sizes and owners, and CPI targets. It is published on the target page and downloadable. This is where hunters start.

Nominating a program

Any upgradeable program can be nominated with its address (POST /api/nominate, or the form on the wall). The address must be an executable program on the upgradeable loader. It then goes through the same OtterSec check at the next refresh and appears on the wall if it qualifies.

curl -X POST https://www.propammengine.xyz/api/nominate \
  -H 'content-type: application/json' \
  -d '{"program":"<program address>"}'

Target of the week

Every Monday at 00:00 UTC the cron picks the top prop AMM without a PASS; launchpads and bonding-curve programs are never chosen. It is shown at the top of the wall and receives the vault's weekly top-up at 00:30 UTC (see $TEARDOWN and the vault).

Previous: OverviewNext: Chipping in