Posting a bounty
The snapshot
Paste a program id. The site reads the program account from mainnet and shows what it found before anything is funded.
| Field | Where it comes from |
|---|---|
| Loader | The program account's owner. Upgradeable loader, loader v2 (and v1), and loader v4 are read; native builtins have no bytecode and are refused. |
| ELF | Upgradeable: the program data account, ELF from byte 45. Loader v2: the account data. Loader v4: from byte 48. Trimmed to the size its ELF header declares. |
| Upgrade authority | From the program data account (upgradeable) or the loader v4 header. Shown as none when the program is frozen. |
| Last deploy slot | The slot stored in the program data account. |
| ELF size and sha256 | Of the trimmed ELF. The page also prints the hash verify.osec.io computes (the account bytes with trailing zeros removed) so both can be compared. |
| Verification | The OtterSec verify API (verify.osec.io/status/<program>). A program already verified open source is refused as a bounty target: its source is already public. |
The snapshot is frozen with the bounty. If the program is upgraded later, the bounty still targets the binary that was snapshotted.
The corpus
When a bounty opens, the judge machine collects recent mainnet transactions that call the program: top-level instructions to it and inner instructions whose program is the target. For each instruction it keeps the data, the account keys with their signer and writable flags, and the transaction's compute budget. It then fetches the current state of every referenced account, and the ELF of every executable account referenced (CPI targets).
The target is 1,000 real instructions. A program with fewer usable recent instructions gets the N that exists, every page prints that real N, and a bounty needs at least 200 to open. The corpus is a deterministic bundle (sorted keys, versioned format) identified by its sha256.
Funding the escrow
Each bounty has its own escrow key, derived by the keeper (m/44'/501'/<bounty number>'/0'), and a USDC account owned by that key. Funding is one transaction built by the site and signed in your wallet: create the escrow's USDC account if it does not exist yet, transfer USDC to it, and attach a Memo.
decomp:fund:<bountyId>
- Minimum 50 USDC to open a bounty.
- Anyone can top up the same bounty. Each top-up is its own transfer with its own Memo.
- The wallet opens only when you click Connect wallet; nothing is requested on page load.
- Positions are read from the chain: the bounty page lists every transfer into the escrow with its signature on Solscan.
Outcomes
On the first PASS, the keeper pays 90% of the escrow to the hunter's payout wallet and routes 10% to the $DECOMP buy and burn, each leg with a Memo. Until $DECOMP exists, that 10% waits in the vault and the bounty page says so.
A bounty with no PASS after 90 days moves to refunding: each backer can withdraw their share, paid back by the keeper with a Memo.
Posters confirm they have a legitimate interest in the program: audit, interoperability or security research.