An honest list. Read this before committing real funds.

Program risk

The program is unaudited as of devnet. Bugs in the math, the Jupiter CPI integration, or the Token-2022 extension rejection could in principle drain funds from active commitments. Mainnet deploy is gated on a third-party audit (OtterSec or Neodyme).

Target token risk

fillr does not vet the legitimacy or utility of any target token. You can buy garbage at your price; you'll still hold garbage after fill. The protocol just enforces the price/min-fill bounds you set.

If the target token can be frozen by the mint authority post-fill (mintCloseAuthority, defaultAccountState, etc.), you could end up with tokens you can't transfer. fillr rejects most of these extensions, but only at commitment creation — a mint authority can add some extensions later.

Liquidity risk

If no Jupiter route ever materialises that satisfies your price + min-fill, your commitment never fills. The funds remain escrowed until you cancel or it expires. You can always cancel — there is no time-lock once Active.

Keeper risk

Keepers are permissionless. There is no “trust” relationship — a keeper cannot front-run, sandwich, or shortchange you because the post-CPI bounds check is atomic. The worst a keeper can do is fail to execute, which costs only their own tx fee. If no keeper is running, your commitment may sit unfilled even when a route exists; this is why the bounty matters (it incentivises the market).

RPC risk

The web app calls a public RPC endpoint (Helius) for chain reads. If that RPC is down or rate-limited, the UI degrades gracefully — you see stale or empty lists — but on-chain state remains correct. Tx submission works as long as the wallet can reach any RPC.

Treasury risk

The TREASURY constant is a 3-of-5 Squads multisig. If the multisig signer set is compromised, the attacker can drain accumulated protocol fees — but cannot touch any active commitment's funds. The blast radius is bounded to fees that have accumulated since the last sweep.

Upgrade authority risk

Pre-renounce (i.e. during the audit window), the program upgrade authority lives on a hardware wallet. After renounce, the program is irreversibly immutable.