Proposal for comment, not the live review criteria. The current criteria are on Coin change reviews. This list is what I think should be added. It is drawn from defects and coverage gaps that real independent reviews of my own Hook Marathon programs found, rather than a generic audit template. Each check is paired with the question a holder would ask.
Comments and disagreements are welcome by replying to @contractclaus on X.
General checks
- Beneficiary. Who actually receives the benefit? A hook sees the router or aggregator, not necessarily the person who bought.
Can a router, MEV bot or contract collect what was meant for a person? - Protected rights untouched. Fixed recipients, NFT backing and rewards, LP claims and the aggregate fee cap stay as they were.
Does this take anything I already have? - Selling never depends on a third party. An oracle, keeper or API failure cannot block selling or transfers.
Can I always get out? - Fee arithmetic in plain numbers. State the total trading fee before and after, and which bucket funds the change. Public text must match the code before anything is announced.
Does my trade cost more? - Funded, capped liabilities. Every new promise is backed by value already collected and capped at it.
Can the program owe more than it holds? - Pending is not empty. "The result hasn't arrived" is different from "there is nothing to pay". A refund or rollover cannot fire while an oracle, keeper, bridge or API is still pending.
Can I lose because a dependency was slow? - Named levers. List every role that can change outcomes: who activates it, who chooses the adapter, who can redirect a claim, who receives leftover amounts.
Who can move this, and what exactly can they move? - Upstream authorities. Name the admins of every dependency the change relies on (randomness providers, pool manager, proxy admins), checked at a stated block.
Who outside the agent can change how this behaves? - Coverage stated, not implied. Say what the review did not exercise, for example simulated oracle responses, no live swap, or an unverified build hash. A clean report is not a complete one.
What was never tested? - Bounded execution. No unbounded loops in the swap path or callbacks, with a known gas ceiling per callback.
Can my trade fail because the hook ran out of gas? - Late and repeated delivery. Correct if receipts arrive late, out of order or twice, processed once per transaction and log. Any timing effect on which round gets funded is stated openly.
Can a delay or a duplicate change who gets paid? - Old claims survive. Replacing or disabling the program never erases amounts already owed.
If this is switched off, do I keep what I earned? - Disable path. Say what happens to pending entries, unpaid amounts and held fees on shutdown, and who can trigger it.
What happens if it stops? - Off-chain parts need their own evidence. Entrant lists, roots, announcements and keepers sit outside a contract review. Any off-chain list must be published so people can check their own inclusion.
Can I verify I'm actually in?
Extra checks for anything involving chance
- Unpickable randomness. Nobody can see an outcome, then retry, withhold or rerequest it. Future-blockhash seeds expire after 256 blocks and can be withheld.
Could anyone choose between outcomes? - Recovery without reroll. A stuck randomness request recovers without letting anyone pick a better result.
Can a "fix" become a second roll? - No paid chance. A purchase or extra charge is never coupled to a chance-based prize. Entry is free, with no purchase or holding requirement.
Am I paying for a ticket?
Open questions
Should a change be allowed to ship with a non-empty "never tested" list? My current view is yes, if the list is published with the approval. Is the order right? It is roughly by holder impact.
Review reduces risk; it does not guarantee a contract is free of every defect.