What is a Keeper
A Keeper does exactly one thing: when conditions are met, submit an already-existing order within the Session's boundaries. It doesn't change the price, the direction, or route user funds to its own address.
Roles and permissions
| Role | Permissions |
|---|---|
| User | Create / cancel orders, revoke Session |
| Keeper | Calls executeOrder(orderId) |
| Relayer (optional) | Pays Gas on the user's behalf, still through the same execution function |
| Protocol multisig | Pause, list/delist adapters, slash disputes |
v1 recommendation: users can also click execute themselves (self-execution). Keepers only raise the on-time fill rate; they are not the only executors.
Who can be a Keeper
- Minimum stake: 50,000 FORGE (before TGE, whitelisted addresses serve; applications are closed)
- Unstake cooldown: 7 days; each Keeper binds a hot wallet; slashes hit the bond
- Before TGE: 3–10 internal Keepers, list maintained by the multisig
- After TGE: automatic entry once the bond qualifies, still subject to health checks (success rate, latency)
Order selection and trigger rules (reproducible)
- Pull Open orders every 1–2 seconds, filtering: not expired, Session valid with enough budget, oracle fresh, token not paused, simulated minOut satisfiable
- Limit buffer (anti-jitter, anti-wick): buy triggers only when
oracle ≤ trigger × (1 − 5bps); sell is symmetric. The buffer is written into the order, visible to the user; default 5bps, max 30bps - Time-based orders:
now ≥ executeAt, no buffer, but slippage is still simulated - Ordering: earliest expiry executes first; same expiry, smaller orderId first
- v1 has no priority-fee bidding market, to reduce self-competition and sandwiching
- Multiple Keepers may try simultaneously; the contract guarantees only one succeeds, the rest revert ALREADY_EXECUTED
Execution window
After triggering, the execution window is at most 120 seconds; executeOrder can be submitted within it. If the window ends without execution → Failed (NOT_PICKED). The window stays short so orders aren't sandwiched while "triggered but unfilled".
Anti-frontrunning / anti-sandwich
- Strict minAmountOut (the floor computed from the user's slippage) is the on-chain hard protection
- Adapters use only whitelisted pool paths; a Keeper can't reroute on the fly
- The execution function has no recipient parameter; the recipient is fixed to order.owner
- Production defaults to private submission (private RPC / relay); the public mempool is fallback-only with an alert
- Short leash in the contract: if the price deviates from the trigger by more than maxDriftBps (50bps) at execution → revert PRICE_DRIFT
- Keeper pay = a fixed ETH tip + a tiny success fee (10% of the protocol fee), never a cut of "worse fills"
Slash rules
| Behavior | Response |
|---|---|
| Successful execution | Success fee paid |
| Normal revert (slippage, already filled) | No penalty |
| Blind execution of untriggered orders causing user loss | Slashed after investigation, manual multisig |
| Routing funds to a non-owner | Should be impossible by design; if an adapter bug allows it, the protocol pauses |
| Always online but never executing triggered orders | Deprioritized, no automatic penalty |
| Key leak spamming garbage txs | That Keeper is paused |
v1 automatic slash covers exactly one case: execute succeeds but amountOut < minOut (the contract should have blocked this; if it still happens = critical bug, pause).
Audits and bug bounty
Reports
Audits are scheduled; PDFs will be published on the security page when complete. Current status: Audits pending.
Scope
ForgeSession / ForgeSpot / ForgeOrders / ForgeExecutor / ForgeFeeVault / UniswapAdapter and the official frontend. See the security page for scope and reward details.
How to submit
The security page provides a submission channel. Do not disclose unfixed bugs in public.
Multisig and pause
Addresses
The 3/5 multisig and Guardian hot wallet addresses are published with contract deployment, matching the explorer.
Pause scope
A pause blocks creation and execution. It does not block cancelling orders or revoking Sessions, and it cannot move user funds.
Timelock
Parameter changes (fees, routing, whitelist) go through the 48-hour timelock; the Guardian hot wallet only pauses, never changes.