Security and trust model

What the operator runs

The judge machine and the keeper are run by the operator. The judge machine is a single machine kept stopped and started per job; it decrypts submissions with its X25519 key, builds them, replays the corpus and posts the reports. The keeper pays fees, signs the Memo records, receives bonds and signs payouts and refunds.

Escrows are held by keeper-derived keys. This is the lite architecture: there is no on-chain program, so the escrow rules are enforced by the keeper's code, not by a contract. Each bounty has its own key and its own USDC account, which keeps every bounty's balance separate and visible on-chain.

What anyone can check

• The binaries' hashes against mainnet: the original's sha256 is printed with the snapshot, next to the hash verify.osec.io computes.
• The corpus bundle, served by its sha256, with the transaction signature of every case.
• The verdict report, served by its sha256, reproducible byte for byte.
• The replay itself, re-run with the public verifier on your own machine.
• Every USDC movement of every escrow on Solscan, each with its Memo.

Submissions

Sources are encrypted in the browser to the judge's key and stay encrypted at rest. A winning source is published on the bounty page for everyone: escrow bounties are always open source on pass. A failing source is not published.

Builds run on an ephemeral machine with a cleared environment and a 10 minute cap. The rules on build scripts, proc-macros, includes and dependency sources exist so a submission cannot run code at build time beyond the allow-listed macros, and cannot smuggle the original bytecode in.

Scope

The protocol serves audit, interoperability and security research on programs deployed publicly on Solana. Posters confirm a legitimate interest; hunters confirm the source is their own work. Rights holders can ask for a bounty to be taken down through the takedown form.