# custody
We can't touch your funds.
Your USDC, USDT, or SOL escrows into a per-order PDA owned by the program. There is no admin key, no multisig override, no withdrawal function we control. The cancel path is open until the moment of execution.
Pre-fill limit orders for @Solana token launches.
how it works
Four steps. Nothing in between.
One atomic instruction. No partial states, no admin overrides, no oracle. The protocol is the rulebook.
- 01
Commit
Lock USDC, USDT, or SOL into a per-order PDA. Set a max price and a min fill. The funds are on-chain, controlled by the program — you keep custody until execution or cancel.
- 02
Watch
A permissionless keeper monitors Jupiter for routability. No oracle, no admin, no privileged signer. Anyone can run a keeper; the first to deliver wins the bounty.
- 03
Fill
When liquidity exists and your price holds, one atomic transaction swaps your escrow for the target token via Jupiter — settling your slippage and min-fill in the same instruction.
- 04
Receive
Tokens land in your wallet. Or cancel any time before fill — funds refund instantly, no timelock, no fee. The Commitment account closes and rent comes back to you.
why fillr
What it can't do, by design.
Four properties baked into the on-chain program. Not promises — not things we could change tomorrow. Code that doesn't allow otherwise.
# atomic
Fill or revert.
The price check, the min-fill check, the Jupiter CPI, and the token delivery all happen inside one Solana instruction. If any constraint fails, the entire transaction reverts. There is no "almost executed" state.
# permissionless
Any keeper, any time.
No allowlist. No oracle. No privileged signer. The bounty is open competition — anyone can spin up a keeper and earn for delivering fills. The first valid execute wins; everyone else's tx reverts cleanly.
# immutable
The protocol is the bytecode.
Upgrade authority renounces post-audit. After that the program cannot be changed by anyone — not by us, not by a governance vote, not by a hacker with the deployer key. The rules are frozen.
None of this requires you to trust us — only to read the program source and the bytecode hash on Solscan.
Program on Solscan ↗protocol
Verified, public, on-chain.The receipts.
Every claim on this page traces to a public Solana account, a commit on GitHub, or an OtterSec verification record. Nothing here requires trusting us.
- License
- MIT
- Cluster
- mainnet-beta
- Security
- support@usefillr.app
- Anchor
- 0.32.0
- Build toolchain
- solana-verifiable-build:2.3.0
- Upgrade authority
- Active — renounces post-audit
Every field above resolves to a public, on-chain source.Verification record ↗
support · faq
Questions, answered.
Common stuff first. If something below doesn't cover what you're hitting, reach us directly — we read every message.
SupportOpen a ticket Real humans on the other end. Replies in < 24h, usually faster.X@use_fillr Status updates, fill confirmations, and the occasional shitpost.
Funds escrow into a per-order PDA owned by the fillr program. There is no admin key, no multisig override, no withdrawal function the team controls. The cancel path is always open until execution, and the source is public + verified — you can audit every account constraint yourself.
The keeper polls Jupiter on a short loop. If no route exists, your commitment sits open. The moment liquidity appears that satisfies your max-price and min-fill, the next keeper poll picks it up and fills atomically in one transaction.
20 bps (0.20%) protocol fee, skimmed off the payment leg into a treasury ATA on execute. You separately set a SOL bounty (default 0.001 SOL) paid to whichever keeper delivers your fill. No fee to cancel; no fee on expiry. Tx fees + account rent are your standard Solana costs.
No. Funds escrow into a per-order PDA controlled by the program's verified bytecode. The team has no admin function, no withdrawal authority, and no multisig override. The treasury address (which receives the 20 bps protocol fee on successful fills) is hardcoded at compile and verified on Solscan. Once upgrade authority renounces post-audit, the program code itself becomes immutable forever.
Anyone can run a keeper — the bounty creates a permissionless market for filling. The default bounty (0.001 SOL) makes most fills profitable for keepers running on $5-10/mo infra. If yours sits unfilled, you can cancel any time before execution and the protocol refunds your escrow + rent immediately.
Yes, but we reject mints with extensions that break atomic price guarantees — transfer fees, transfer hooks, permanent delegate, non-transferable, default-frozen, confidential transfer, interest-bearing, pausable. Standard SPL Token mints and benign Token-2022 mints (metadata-pointer, immutable-owner, etc.) work fine.
Pending. The program is currently deployed with upgrade authority still active so we can patch bugs surfaced during the audit. We won't renounce upgrade authority until the audit closes clean. See /docs/audits for the current status and audit firm shortlist.
The reference keeper is a small TypeScript service we run today. Once we cut the public keeper SDK, anyone will be able to spin one up in a few minutes — Helius gRPC subscription + Jupiter quote API + sign + submit. Email support@usefillr.app if you want early access to the reference implementation.
More detail in the docs.Full FAQ ↗