Skip to main content
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.

​
Adversaries

AdversaryWhat they tryHow the contracts refuse
Whale manipulatorInfluence filter outcome via late-stage HP gaming or coordinated buys at the cutHP component math limits velocity dominance; concentration component penalizes buys-from-few-addresses; multi-component scoring resists single-vector attacks
Settlement front-runnerInsert 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 attackerRe-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 gamerClaim rollover or bonus they didn’t earn, or claim more than onceMerkle root is immutable post-publish; proof verification at claim time; per-claim nullifier prevents replay
Oracle impersonatorSubmit settlement as a non-oracle addressmsg.sender checked against immutable oracle address at function entry; no upgrade mechanism replaces the oracle without explicit governance action
Storage corrupterSet 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 exploiterExtract value via rounding errors in divisionExplicit dust accounting: rounding routes to treasury; never disappears; never accumulates in an unaccounted contract balance

​
Why these seven

These are the categories of attack the contracts are designed to refuse — 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 by 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.