A threat model is not the same as a list of risks. Risks are what can happen to participants in the game (see Risks). A threat model is what attackers might try against the contracts, and what the contracts do to refuse them.The pipeline assumes attackers are adversarial, well-funded, and patient. The defenses below are not “we trust people not to do this” — they are enforced at the contract level, with Foundry invariant tests proving they hold.Documentation Index
Fetch the complete documentation index at: https://docs.filter.fun/llms.txt
Use this file to discover all available pages before exploring further.
Adversaries
| Adversary | What they try | How the contracts refuse |
|---|---|---|
| Whale manipulator | Influence filter outcome via late-stage HP gaming or coordinated buys at the cut | HP component math (spec §6.4) limits velocity dominance; concentration component (spec §41) penalizes buys-from-few-addresses; multi-component scoring resists single-vector attacks |
| Settlement front-runner | Insert transactions between filter and settlement to extract value (MEV-style sandwich on POL deployment) | Settlement is atomic and oracle-only; POL deployment runs inside the same transaction as submitWinner; deterministic execution paths leave no value to extract |
| Reentrancy attacker | Re-enter state-mutating functions during external calls (e.g., transfer hooks calling back into the pipeline) | ReentrancyGuard on every state-mutating function in SeasonVault, TournamentVault, BonusDistributor, POLManager, CreatorRegistry; fuzzed against malicious receivers |
| Merkle proof gamer | Claim rollover or bonus they didn’t earn, or claim more than once | Merkle root is immutable post-publish; proof verification at claim time; per-claim nullifier prevents replay |
| Oracle impersonator | Submit settlement as a non-oracle address | msg.sender checked against immutable oracle address at function entry; no upgrade mechanism replaces the oracle without explicit governance action |
| Storage corrupter | Set contract state to malicious values via misuse of admin functions (e.g., zero-address oracle, out-of-range BPS) | Input validation on every admin setter; zero-address rejection; out-of-range values reject; one-shot setters for critical wires (factory ↔ hook ↔ launcher) |
| Dust exploiter | Extract value via rounding errors in division | Explicit dust accounting: rounding routes to treasury per spec §11; never disappears; never accumulates in an unaccounted contract balance |
Why these seven
The list mirrors spec §42.1 and reflects the categories of attack the contracts are designed to refuse — meaning each one has named code paths and named tests. It is not a complete enumeration of every possible attack on a smart-contract system. It is the set the team has modeled explicitly and built defenses for.If you find an attack that doesn’t fit one of these seven categories, that’s exactly the kind of finding the voluntary disclosure window exists to surface.What this model does NOT cover
- Off-chain trust assumptions — the indexer, oracle, scheduler, and web app are out of scope for this on-chain threat model. Their failure modes matter, but they are not what the settlement contracts defend against.
- Economic attacks at the game-design layer — wash trading, reflexive HP feedback loops, coordinated whale strategies. These are game-theory questions covered in spec §16.6 and the HP component design, not the contract threat model.
- Third-party dependencies — Uniswap V4 PoolManager, WETH9. filter.fun inherits their threat models without re-stating them here.